Cloud-based clinical distribution systems and methods of use

ABSTRACT

Example systems and methods for cloud-based clinical content distribution and/or messaging are disclosed and described herein. An example apparatus includes an edge device to mediate between a local information system associated with a local cloud system and a remote cloud system. The example edge device analyzes the healthcare information by matching the healthcare information to a first characteristic or a second characteristic. When the healthcare information matches the first characteristic, the edge device uploads the healthcare information to the remote cloud system and allocates a first computing task to the remote cloud system for the healthcare information. When the healthcare information matches the second characteristic, the edge device stores the healthcare information at the local cloud system and allocates a second computing task to the local cloud system for the healthcare information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent arises as a divisional of U.S. patent application Ser. No.14/952,258, entitled “Cloud-Based Clinical Distribution Systems andMethods Of Use” which was filed on Nov. 25, 2015, which claims priorityto U.S. Provisional Application Ser. No. 62/085,236, entitled“CLOUD-BASED CLINICAL DISTRIBUTION SYSTEMS AND METHODS OF USE,” whichwas filed on Nov. 26, 2014, each of which is herein incorporated byreference in their entireties.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[Not Applicable]

MICROFICHE/COPYRIGHT REFERENCE

[Not Applicable]

BACKGROUND

Healthcare entities such as hospitals, clinics, or clinical groups oftenemploy local information systems to store and manage patientinformation. If a first healthcare entity having a first localinformation system refers a patient to a second healthcare entity havinga second local information system, personnel at the first healthcareentity typically manually retrieves patient information from the firstinformation system and stores the patient information on a storagedevice such as a compact disk (CD). The personnel then transport thestorage device to the second healthcare entity, which employs personnelto upload the patient information from the storage device onto thesecond information system.

BRIEF SUMMARY

In view of the above, systems, methods, and computer program productswhich improve connections within a healthcare ecosystem are provided.Example systems, methods, and apparatus can facilitate hybridcloud-based interaction, storage, and messaging. The above-mentionedneeds are addressed by the subject matter described herein and will beunderstood in the following specification.

This summary briefly describes aspects of the subject matter describedbelow in the Detailed Description, and is not intended to be used tolimit the scope of the subject matter described in the presentdisclosure.

Certain examples provide a cloud-based clinical distribution apparatusincluding an edge device including a particularly programmed processorconfigured to mediate between (a) a local information system associatedwith a local cloud system and (b) a remote cloud system. The exampledisclosed edge device is configured to analyze healthcare informationgenerated by the local information system to determine whether to uploadthe healthcare information to the remote cloud system or store thehealthcare information at the local cloud system. The example disclosededge device is configured to analyze the healthcare information bymatching the healthcare information to a first characteristic or asecond characteristic. When the healthcare information matches the firstcharacteristic, the edge device is to automatically upload thehealthcare information to the remote cloud system and allocates a firstcomputing task to the remote cloud system for the healthcareinformation. When the healthcare information matches the secondcharacteristic, the edge device is to automatically store the healthcareinformation at the local cloud system and allocates a second computingtask to the local cloud system for the healthcare information.

Certain examples provide a method to integrate a local informationsystem with a cloud-based clinical distribution system. The exampledisclosed method includes analyzing, using a particularly programmedprocessor, healthcare information generated by a local informationsystem to determine whether to upload the healthcare information to aremote cloud system or store the healthcare information at a local cloudsystem associated with the local information system by matching thehealthcare information to a first characteristic or a secondcharacteristic. The example disclosed method includes, when thehealthcare information matches the first characteristic, automaticallyuploading the healthcare information to the remote cloud system andallocating a first computing task to the remote cloud system for thehealthcare information. The example disclosed method includes, when thehealthcare information matches the second characteristic, automaticallystoring the healthcare information at the local cloud system andallocating a second computing task to the local cloud system for thehealthcare information.

Certain examples provide a tangible computer-readable storage mediumincluding instructions which, when executed, particularly program aprocessor and cause the processor to implement a cloud-based clinicaldistribution apparatus. The example disclosed apparatus including anedge device including a particularly programmed processor configured tomediate between (a) a local information system associated with a localcloud system and (b) a remote cloud system. The example disclosed edgedevice is configured to analyze healthcare information generated by thelocal information system to determine whether to upload the healthcareinformation to the remote cloud system or store the healthcareinformation at the local cloud system. The example disclosed edge deviceis configured to analyze the healthcare information by matching thehealthcare information to a first characteristic or a secondcharacteristic. When the healthcare information matches the firstcharacteristic, the edge device is to automatically upload thehealthcare information to the remote cloud system and allocates a firstcomputing task to the remote cloud system for the healthcareinformation. When the healthcare information matches the secondcharacteristic, the edge device is to automatically store the healthcareinformation at the local cloud system and allocates a second computingtask to the local cloud system for the healthcare information.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is illustrates an example cloud-based clinical information systememployed by a first healthcare entity to share information with a secondhealthcare entity.

FIG. 2 is a block diagram illustrating an example hierarchalorganizational system employed by the example cloud-based clinicalinformation system of FIG. 1.

FIG. 3 illustrates an example architecture that may be used to implementthe example cloud-based clinical information system of FIG. 1.

FIG. 4 illustrates an example architecture that may be used to implementthe example cloud-based clinical information system of FIG. 1.

FIG. 5 illustrates an example architecture that may be used to implementthe example cloud-based clinical information system of FIG. 1.

FIG. 6 is a flow diagram illustrating an example workflow to register ahealthcare entity with the example cloud-based clinical informationsystem.

FIG. 7 is a flow diagram illustrating an example workflow to enroll afirst healthcare entity with a second healthcare entity to enable thefirst healthcare entity and the second healthcare entity to shareinformation via the example cloud-based clinical information system ofFIG. 1.

FIG. 8 is a flow diagram illustrating an example workflow of an exampleuser interface which may be used to implement the example cloud-basedclinical information system of FIG. 1.

FIG. 9 illustrates an example user interface disclosed herein.

FIG. 10 illustrates an example user interface disclosed herein.

FIG. 11 illustrates another example user interface disclosed herein.

FIG. 12 illustrates the example cloud-based clinical information systememployed to integrate a first local information system and a secondlocal information system of a healthcare entity with the cloud-basedclinical information system.

FIG. 13 illustrates an example workflow to automatically generatepatient and/or exam records in the first local information system ofFIG. 12.

FIG. 14 illustrates an example workflow to automatically generatepatient and/or exam records in the first local information system andthe second local information system of FIG. 12.

FIGS. 15-17 illustrate a flowchart representative of examplemachine-readable instructions which may be executed to automaticallyattach healthcare information stored in the cloud-based clinicalinformation system of FIG. 12 to a patient record in the first localinformation system and/or the second local information system.

FIGS. 18-20 illustrate a flowchart representative of examplemachine-readable instructions which may be executed to register a firsthealthcare entity with the cloud-based clinical information system ofFIG. 3 and enroll the first healthcare entity with a second healthcareentity registered with the example cloud-based clinical informationsystem.

FIGS. 21-22 illustrate a flowchart representative of examplemachine-readable instructions which may be executed to implement anexample hybrid cloud system disclosed herein.

FIG. 23 illustrates an example data bus aware architecture.

FIG. 24 depicts an example data bus aware system sequence.

FIG. 25 shows a flow diagram of an example data bus aware process.

FIG. 26 illustrates an example data distribution services architecture.

FIG. 27 is a block diagram of an example processor platform that may beused to implement the example systems and methods disclosed herein.

The foregoing summary, as well as the following detailed description ofcertain embodiments of the present invention, will be better understoodwhen read in conjunction with the appended drawings. For the purpose ofillustrating the invention, certain embodiments are shown in thedrawings. It should be understood, however, that the present inventionis not limited to the arrangements and instrumentality shown in theattached drawings.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings that form a part hereof, and in which is shown byway of illustration specific examples that may be practiced. Theseexamples are described in sufficient detail to enable one skilled in theart to practice the subject matter, and it is to be understood thatother examples may be utilized and that logical, mechanical, electricaland other changes may be made without departing from the scope of thesubject matter of this disclosure. The following detailed descriptionis, therefore, provided to describe example implementations and not tobe taken as limiting on the scope of the subject matter described inthis disclosure. Certain features from different aspects of thefollowing description may be combined to form yet new aspects of thesubject matter discussed below.

When introducing elements of various embodiments of the presentdisclosure, the articles “a,” “an,” “the,” and “said” are intended tomean that there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements.

Cloud-based clinical information systems and methods of use aredisclosed and described herein. An example cloud-based clinicalinformation system described herein enables healthcare entities (e.g.,patients, clinicians, sites, groups, communities, and/or other entities)to share information via web-based applications, cloud storage and cloudservices. For example, the cloud-based clinical information system mayenable a first clinician to securely upload information into thecloud-based clinical information system to allow a second clinician toview and/or download the information via a web application. Thus, forexample, the first clinician may upload an x-ray image into thecloud-based clinical information system, and the second clinician mayview the x-ray image via a web browser and/or download the x-ray imageonto a local information system employed by the second clinician.

In some examples, a first healthcare entity may register with thecloud-based clinical information system to acquire credentials and/oraccess the cloud-based clinical information system. To share informationwith a second healthcare entity and/or gain other enrollment privileges(e.g., access to local information systems), the first healthcare entityenrolls with the second healthcare entity. In some examples, the examplecloud-based clinical information system segregates registration fromenrollment. For example, a clinician may be registered with thecloud-based clinical information system and enrolled with a firsthospital and a second hospital. If the clinician no longer chooses to beenrolled with the second hospital, enrollment of the clinician with thesecond hospital can be removed or revoked without the clinician losingaccess to the cloud-based clinical information system and/or enrollmentprivileges established between the clinician and the first hospital.

In some examples, business agreements between healthcare entities areinitiated and/or managed via the cloud-based clinical informationsystem. For example, if the first healthcare entity is unaffiliated withthe second healthcare entity (e.g., no legal or business agreementexists between the first healthcare entity and the second healthcareentity) when the first healthcare entity enrolls with the secondhealthcare entity, the cloud-based clinical information system providesthe first healthcare entity with a business agreement and/or terms ofuse that the first healthcare entity executes prior to being enrolledwith the second healthcare entity. The business agreement and/or theterms of use may be generated by the second healthcare entity and storedin the cloud-based clinical information system. In some examples, basedon the agreement and/or the terms of use, the cloud-based clinicalinformation system generates rules that govern what information thefirst healthcare entity may access from the second healthcare entityand/or how information from the second healthcare entity may be sharedby the first healthcare entity with other entities and/or other rules.

In some examples, the cloud-based clinical information system may employa hierarchal organizational scheme based on entity types to facilitatereferral network growth, business agreement management, and regulatoryand privacy compliance. Example entity types include patients,clinicians, groups, sites, integrated delivery networks, communitiesand/or other entity types. A user, which may be a healthcare entity oran administrator of a healthcare entity, may register as a given entitytype within the hierarchal organizational scheme to be provided withpredetermined rights and/or restrictions related to sending informationand/or receiving information via the cloud-based clinical informationsystem. For example, a user registered as a patient may receive or shareany patient information of the user while being prevented from accessingany other patients' information. In some examples, a user may beregistered as two types of healthcare entities. For example, ahealthcare professional may be registered as a patient and a clinician.

In some examples, the cloud-based clinical information system includesan edge device located at healthcare facility (e.g., a hospital). Theedge device may communicate with a protocol employed by the localinformation system(s) to function as a gateway or mediator between thelocal information system(s) and the cloud-based clinical informationsystem. In some examples, the edge device is used to automaticallygenerate patient and/or exam records in the local information system(s)and attach patient information to the patient and/or exam records whenpatient information is sent to a healthcare entity associated with thehealthcare facility via the cloud-based clinical information system.

In some examples, the cloud-based clinical information system generatesuser interfaces that enable users to interact with the cloud-basedclinical information system and/or communicate with other usersemploying the cloud-based clinical information system. An example userinterface described herein enables a user to generate messages, receivemessages, create cases (e.g., patient orders), share information,receive information, view information, and/or perform other actions viathe cloud-based clinical information system.

FIG. 1 illustrates an example cloud-based clinical information system100 disclosed herein. In the illustrated example, the cloud-basedclinical information system 100 is employed by a first healthcare entity102 and a second healthcare entity 104. As described in greater detailbelow, example entity types include a community, an integrated deliverynetwork (IDN), a site, a group, a clinician, and a patient and/or otherentities.

In the illustrated example, the first healthcare entity 102 employs theexample cloud-based clinical information system 100 to facilitate apatient referral. Although the following example is described inconjunction with a patient referral (e.g., a trauma transfer), thecloud-based information system 100 may be used to share information toacquire a second opinion, conduct a medical analysis (e.g., a specialistlocated in a first location may review and analyze a medical imagecaptured at a second location), facilitate care of a patient that istreated in a plurality of medical facilities, and/or in other situationsand/or for other purposes.

In the illustrated example, the first healthcare entity 102 may be amedical clinic that provides care to a patient. The first healthcareentity 102 generates patient information (e.g., contact information,medical reports, medical images, and/or any other type of patientinformation) associated with the patient and stores the patientinformation in a first local information system (e.g., PACS/RIS and/orany other local information system). To refer the patient to the secondhealthcare entity 104, the first healthcare entity posts or uploads anorder 106, which includes relevant portions of the patient information,to the cloud-based clinical information system 100 and specifies thatthe patient is to be referred to the second healthcare entity. Forexample, the first healthcare entity 102 may use a user interface (FIGS.9-11) generated via the cloud-based clinical information system 100 toupload the order 106 via the internet from the first local informationsystem to the cloud-based clinical information system 100 and direct thecloud-based information system 100 notify the second healthcare entity104 of the referral and/or enable the second healthcare entity 104 toaccess the order 106. In some examples, the cloud-based clinicalinformation system 100 generates a message including a secure link tothe order 106 and emails the message to the second healthcare entity104. The second healthcare entity 104 may then view the order 106through a web browser 108 via the cloud-based clinical informationsystem 100, accept and/or reject the referral, and/or download the order106 including the patient information into a second local informationsystem (e.g., PACS/RIS) of the second healthcare entity 104. Asdescribed in greater detail below, the cloud-based-based clinicalinformation system 100 manages business agreements between healthcareentities to enable unaffiliated healthcare entities to shareinformation, thereby facilitating referral network growth.

FIG. 2 illustrates an example hierarchal organization scheme 200disclosed herein. In some examples, credentials are assigned and/orrules for accessing (e.g., viewing, receiving, downloading, etc.)information and/or sharing (e.g., uploading, sending, etc.) informationvia the cloud-based clinical information system 100 is governed and/ordetermined by the cloud-based information system 100 according to thehierarchal organization scheme 200. In the illustrated example, thehierarchal organizational scheme 200 is organized based on entity types.In the illustrated example, the entity types include communities 202,204, IDNs 206, 208, sites 210, 212, 214, 216, groups 218, 220,clinicians 222, 224, 226, 228, 230, 232, 234, and patients 234, 236,238, 240, 242, 244, 246, 248, 250, 252. Other examples include otherentity types.

In some examples, the communities 202, 204 are legal entities. In someexamples, the communities 202, 204 are defined by subject matter (e.g.,medical practice type, research area and/or any other subject matter)and/or geographic location. For example, the community 202 may be aplurality of individuals, hospitals, research facilities, etc.cooperating to form a research collaboration.

The IDNs 206, 208 may be a plurality of facilities and/or providers thatprovide a continuum of care to a market or geographic area. For example,the IDN 206 may be a plurality of medical facilities having businessand/or legal relationships.

The sites 210, 212, 214, 216 are medical facilities such as a hospitals,imaging centers and/or any other type of medical facility.

The groups 218, 220 are a plurality of individuals having a legal-basedor interest-based relationship. For example, the group 218 may be alimited liability corporation, and the group 220 may be composed of aplurality of clinicians.

Clinicians 222, 224, 226, 228, 230, 232, 234 are healthcareprofessionals such as physicians, technicians, administrativeprofessionals (e.g., file room clerks, scheduling administrators,reporting administrators, and/or any other administrativeprofessionals), nurses, students, researchers, and/or any otherhealthcare professionals. In some examples, the clinicians 222, 224,226, 228, 230, 232, 234 are employed by one or more of the sites 210,212, 214, 216 and/or the groups 218, 220.

The patients 234, 236, 238, 240, 242, 244, 246, 248, 250, 252 areindividuals who will be or have been under the care of one or more ofthe clinicians 222, 224, 226, 228, 230, 232, 234.

In the illustrated example, credentials and/or rules for accessing andsharing information via the cloud-based clinical information system 100are assigned and/or governed based on the entity types. Example rulesfor accessing and sharing information via the cloud-based clinicalinformation system 100 include rules related to regulatory complianceand privacy such as, for example, rules to comply with the HealthInsurance Portability and Accountability Act (HIPAA). For example, oneof the patients 234, 236, 238, 240, 242, 244, 246, 248, 250, 252 mayaccess his/her patient information from any healthcare entity incommunication with the cloud-based clinical information system 100 andshare his/her patient information with any healthcare entity incommunication with the cloud-based clinical information system 100.However, the cloud-based clinical information system 100 prohibits orprevents the patients 234, 236, 238, 240, 242, 244, 246, 248, 250, 252from viewing, receiving or sharing other patients' information. In someexamples, the cloud-based clinical information system 100 enables theclinicians 222, 224, 226, 228, 230, 232, 234 to view, receive and/orshare information related to any of the patients 234, 236, 238, 240,242, 244, 246, 248, 250, 252 which are under the clinicians' care.However, the cloud-based clinical information system 100 may prevent oneof the clinicians 222, 224, 226, 228, 230, 232, 234 from viewing and/orsharing information related to one of the patients 234, 236, 238, 240,242, 244, 246, 248, 250, 252 not under the clinicians' care.

In some examples, one healthcare entity is a member of one or more otherhealthcare entities. For example, as illustrated in FIG. 2, theclinician 232 is a member of the group 220 and the site 216. Thus, theclinician 232 may access and/or share information that is accessible tothe group 220 and the site 216 and associated with the clinician 232 viathe cloud-based clinical information system 100. For example, theclinician 232 may be employed by both the group 220 and the site 216,and the clinician 232 may use the cloud-based clinical informationsystem 100 to access and/or share information related to patients underthe care of the clinician 232 at either of the group 220 and the site216 even if, for example, the group 220 and the site 216 are notaffiliated with each other. As described in greater detail below, afirst healthcare entity (e.g., the clinician 222) may become a member ofsecond healthcare entity (e.g., IDN 206) by enrolling in the secondhealthcare entity via the cloud-based clinical information system.

FIG. 3 illustrates example architecture 300 to implement the examplecloud-based clinical information system 100 of FIG. 1. In theillustrated example, the cloud-based clinical information system 100includes a remote cloud system 302 (“cloud,” “remote cloud”) having aweb/user interface tier 304, a service tier 306 and a storage tier 308.In the illustrated example, the clinician 234 is located at the site210. An example edge device 310 is located at the site 234 andfacilitates communication between the remote cloud system 302 and localinformation systems 312, 314 employed by the site 210. For example, theedge device 310 may communicate via Digital Imaging and Communicationsin Medicine (DICOM) and/or Health Level Seven (HL7) protocols with thelocal information systems 312, 314 to generate patient and/or examrecords in the local information systems 312, 314, retrieve informationfrom the local information system 312, 314 and upload the informationinto the cloud 300, store information in the local information systems312, 314, and/or perform other actions. In some examples, the localinformation systems 312, 314 include picture archiving and communicationsystems (PACS), electronic health records (EMR) systems, radiologyinformation systems (RIS) and/or other types of local informationsystems.

In some examples, the web/user interface tier 304 implements a userinterface generator to build a user experience. In some examples, theinterface generator builds a user experience via model-view-controllerarchitecture 316 including views 318, controllers 320 and models 322.For example, the views 318 request information from the models 322 togenerate user interfaces that enable the clinician 234 and/or thepatient 224 to view information stored in the remote cloud system 302via the storage tier 308. In some examples, views 318 generate zerofootprint viewers that enable the clinician 234 and/or the patient 224to view information such as medical images using a web browser. In someexamples, the views 318 generate user interfaces that enable theclinician 234 and/or the patient 224 to upload information onto theremote cloud system 302, download information from the remote cloudsystem 302 onto one or more of the local information systems 312, 314and/or perform other actions. The example models 322 include underlyingdata structures that include and/or organize information used by theviews 318 to populate the user interfaces. The example controllers 320request data from the service tier 306, update the models 322 and/orinformation employed by the models 322 and instruct the views 318 toadjust or change a presentation (e.g., change a screen, scroll, and/orany other adjustment or change to a presentation) provided via the userinterfaces.

The example service tier 306 includes notification services 324, eventbased services 326, 328 employing a publishing-subscribing messagingmodel, application or web services 330, data services 332, identitymanagement services 334 and/or other services. The example storage tier308 includes a plurality of storage devices 336, 338, 340 (e.g.,databases, blobs, image management and storage devices, and/or any otherstorage devices). The example notification services 324 generate andcommunicate (e.g., via email, text message and/or any other way)notifications to users of the example cloud-based clinical informationsystem 100. For example, if the clinician 234 is referred a case via thecloud-based clinical information system 100, the notification services324 may generate and communicate a text message to a phone associatedwith the clinician 234 that indicates that information related to thecase is accessible via the cloud-based clinical information system 100.The example application services 330 and the identity managementservices 334 cooperate to provide and/or verify user credentials and/ormanage rights associated with healthcare entities, register healthcareentities with the cloud-based clinical information system, enrollhealthcare entities with other healthcare entities and/or manage rulesrelated to the healthcare entities accessing and sharing information viathe cloud-based clinical information system 100, and/or perform otheractions. In some examples, the application services 330 and/or theidentity management services 334 implement a registration manager toassign credentials to a healthcare entity to enable the healthcareentity to employ the cloud-based clinical information system 100. Insome examples, the credentials grant the healthcare entity access rightsand sharing rights to access and share, respectively, healthcareinformation associated with the healthcare entity via the cloud-basedclinical information system. In some examples, the first access rightsand the first sharing rights are based on which type of entity is thehealthcare entity. For example, if the healthcare entity is registeredas a patient, the application services 330 and/or the identitymanagement services 334 may prevent the user from accessing informationrelated to other patients.

In some examples, the application services 330 and/or the identitymanagement services 334 implement an agreement manager to store acontractual agreement between two or more healthcare entities. In someexamples, the application services 330 and/or the identity managementservices 334 implement an enrollment manager to assign rules to a firsthealthcare entity defining a least one of access rights or sharingrights to healthcare information associated with a second healthcareentity. In some examples, the access or sharing rights are based on thecontractual agreement and one or more selections by a user associatedwith the second healthcare entity. For example, the user associated withthe second healthcare entity may prevent the first healthcare entityfrom sharing the healthcare information, specify which healthcareentities the first healthcare entity may share the health informationwith via the cloud-based clinical information system, and/or selectother access and/or sharing rights. In some examples, the user interfacetier 304 and the service tier 306 interact asynchronously. For example,the controllers 320 may communicate a request for information stored inan image management and storage device (e.g., storage device 340) viathe data services 332, and the request may be input into a worklist orqueue of the service tier 306. Other architectures are used in otherexamples.

As described in conjunction with FIG. 1 above, the example cloud-basedclinical information system 100 may be used to share information betweenhealthcare entities such as the patient 224 and the site 210. Forexample, the clinician 234 may prepare a medical report and upload themedical report onto the remote cloud system 302 via a user interfacegenerated by the example user interface tier 304. The examplenotification services 324 may notify the patient 224 that the report isaccessible via the cloud-based clinical information system 100, and thepatient may use a web browser to view the report via a zero footprintviewer generated by the views 318. In some examples, the applicationservices 330 implements a case history generator to generate a casehistory related to a patient. For example, the case history generatormay attach healthcare information such as a medical report, a messagegenerated by a clinician, etc. to one or more records and/or otherhealthcare information related to the patient to generate a casehistory. In some examples, the case history generator attachesinformation uploaded from a plurality of healthcare entities to apatient record to generate a case history.

In some examples, the cloud-based clinical information system 100 is ahybrid cloud system including the remote cloud system 302 and a localcloud system 342. For example, the cloud-based clinical informationsystem 100 may enable the site 210 to share information withunaffiliated healthcare entities via the remote cloud system 302 andshare information with affiliated healthcare entities via the localcloud system 342 and/or the remote cloud system 302. In some examples,the remote cloud system 302 and the local cloud system 342 arehierarchal. For example, the cloud-based clinical information system 100may allocate or divide tasks, information, etc. between the remote cloudsystem 302 and the local cloud system 342 based on resources and/or dataavailability, confidentiality, expertise, content of information, a typeof clinical case associated with the information, a source of theinformation, a destination of the information, and/or or other factorsor characteristics. Some example cloud-based clinical informationsystems do not employ the local cloud system 342.

The example local cloud system 342 of FIG. 3 is implemented by theexample edge device 310. In some examples, the edge device 310 employs asubstantially similar architecture to the example architecture 300 ofthe remote cloud system 302 of FIG. 3 to implement the example localcloud system 342. Thus, the example local cloud system 342 may generateuser interfaces, perform notification services, manage and store data,and/or perform other actions and/or services that can be used byhealthcare entities affiliated with the site 210. In some examples, thelocal cloud system 342 functions as a backup to the remote cloud system302 with respect to information related to the site 210 and/or functionas a backup to the local information systems 312, 314. In some examples,the local cloud system 342 employs a different architecture than thearchitecture 300 of the remote cloud system 302 and/or performsdifferent services than the remote cloud system 302.

In some examples, the edge device uploads information from the localinformation systems 312, 314 to the local cloud system 342 and/or theremote cloud system 302. In some examples, the edge device 310 analyzesinformation generated by, stored in and/or used by the local informationsystems 312, 314 and determines which information is to be uploaded ontothe remote cloud system 302 and/or which information is to be uploadedonto the local cloud system 342. In some examples, the edge device 310determines that information is to be uploaded in only one of the remotecloud system 302 or the local cloud system 342. In some examples, theedge device 310 determines that information is to be uploaded to boththe remote cloud system 302 and the local cloud system 342. In someexamples, information from the local information systems 312, 314 and/orfrom the affiliated healthcare entities is routed through the exampleedge device 310 to enable the edge device to analyze the information todetermine if the information is to be uploaded onto the remote cloudsystem 302 and/or the local cloud system 342.

In some examples, information is uploaded onto the local cloud system342 based a type of the information and/or content of the information.For example, the edge device 310 may monitor information stored inand/or used by the local information systems 312, 314 and/orcommunicated between the site 210 and affiliated healthcare entity(ies)to determine types and/or content of information and, based on the typesand/or content of information, upload the information onto the remotecloud system 302 and/or local cloud system 342. For example, informationrelated to clinical care of patients may be uploaded and stored in thelocal cloud system 342. In some examples, the information is stored inthe local cloud system 342 temporarily. For example, if a patient isundergoing a surgical procedure at the site 210, information related tothe surgical procedure and the patient may be stored in the local cloudsystem 342 and accessible via the local cloud system 342 throughout thesurgical procedure. Following the surgical procedure, the informationmay be removed from the local cloud system 342 and/or forwarded to theremote cloud system 302. In some examples, information that is to beused only by healthcare personnel at the site 210 is stored in the localcloud system 342. For example, information related to internal policiesof the site 210 may be stored in the local cloud system 342. In otherexamples, information is uploaded onto the local cloud system 342 forother reasons and/or based on other factors and/or determinations.

In some examples, information is uploaded onto the remote cloud system302 based on a type of information. For example, information to beaccumulated for clinical analysis (e.g., as part of a long-term study)may be uploaded onto the remote cloud system 302. In some example,information to be accessible to healthcare entities other than the site210 is uploaded onto the remote cloud system 302 by the edge device 310.For example, if the clinician 234 refers a patient to another healthcareentity via the cloud-based clinical information system 100, the edgedevice 310 retrieves information related to the patient from the localinformation systems 312, 314 and uploads the information to the remotecloud system 302. In other examples, the edge device 310 uploadsinformation to the remote cloud system 302 for other reasons and/orbased on other factors and/or determinations.

In some examples, the edge device 310 uploads information onto theremote cloud system 302 and/or the local cloud 310 based a case typeassociated with the information and/or a business and/or legalrelationship between a source of the information (e.g., the site 210)and a destination of the information (e.g., an affiliated healthcareentity or an unaffiliated healthcare entity). Case types include, forexample, a trauma case, a specialty case (e.g., an oncology case), asecond opinion case, a clearing house case, an image distribution case,a patient referral case, a foreign study management case, a remoteinterpretation case, a specialty treatment planning case, a review boardcase, a teaching case, a research exchange case and/or other case types.As described in greater detail below in conjunction with FIG. 7, theedge device 310 may determine if healthcare entities are affiliated orunaffiliated based on business and/or legal agreements uploaded, managedand/or utilized by the example remote cloud system 302 and/or theexample local cloud system 342 that are used to establish credentials,access rights and/or sharing rights, and/or the privileges for thehealthcare entities via the cloud-based clinical information system 100.

A trauma case arises when the clinician 234 is treating a patient inneed of a higher level of trauma treatment that is not available at thesite 210. The clinician 234 sends the patient to a healthcare facilitywith higher trauma treatment capabilities and shares information relatedto the patient with a clinician at the healthcare facility via thecloud-based clinical information system 100. In some examples, theinformation related to the trauma case is uploaded onto the local cloudsystem 342 by the edge device 310 and not uploaded onto the remote cloudsystem 302 if the healthcare facility is affiliated with the site 210 toconserve time and/or costs associated with bandwidth usage. In someexamples, the edge device 210 uploads the information related to thetrauma case onto the local cloud system 342 and the remote cloud system302.

A specialty case arises when the clinician 234 is treating a patient inneed of specialty treatment not available at the site 210. The clinician234 sends the patient to another healthcare facility that provides thespecialty treatment and shares information related to the specialty caseto a clinician at the other healthcare facility via the hybrid cloudsystem. In some examples, the information is uploaded onto local cloudsystem 342 by the edge device 310 if the healthcare facility isaffiliated with the site to conserve time and/or costs associated withbandwidth usage. In some examples, the edge device 310 uploads theinformation related to the specialty case onto the local cloud system342 and the remote cloud system 302.

A second opinion case arises when the clinician 234 has diagnosed apatient and would like to receive affirmation of the diagnosis from aclinician located at another healthcare facility. The clinician 234shares information related to the second opinion case to a clinician atthe other healthcare facility via the cloud-based clinical informationsystem 100. In some examples, the information is uploaded onto localcloud system 342 by the edge device 310 if the healthcare facility isaffiliated with the site 210 to conserve time and/or costs associatedwith bandwidth usage, but the edge device 310 does not upload theinformation onto the remote cloud system 302 unless instructed by theclinician 234.

A clearing house case arises when the site 210 sends information relatedto a plurality of cases to a clearing house healthcare entity tostandardize case demographics and/or other clinical characteristic toenable ingestion of the information into the site 210. In some examples,if the clearing house healthcare entity is affiliated with the site 210,the information is shared via the cloud-based clinical informationsystem 100, and the edge device 310 uploads the information onto thelocal cloud system 342 and not onto the remote cloud system 302. In someexamples, the local cloud system 342 performs demographicstandardization of the information and enables the clinician 234 and/orother healthcare professionals to view the information via a zerofootprint viewer.

An image distribution case arises when the site 210 sends information toa generic healthcare entity that will be accessed by a group ofclinicians or users remotely providing case review. If the generichealthcare entity is affiliated with the site 210, the edge device 310shares the information via the local cloud system 342.

A patient referral case arises when the clinician 234 is a generalpractitioner and requests a specialist to review a patient case throughan affiliated, disconnected network. In some examples, the edge device310 shares information related to the patient case to the specialist viathe local cloud system 342 and not via the remote cloud system 302. Insome examples, the edge device 310 shares the information via the localcloud system 342 and uploads the information onto the remote cloudsystem 302.

A foreign study management case arises when the site 210 receives alarge volume of cases involving studies that are to be managed, routedand/or classified to enable the studies to be ingested by one or more ofthe local information systems 312, 314. In some examples, theinformation is received via one or more portable storage devices (e.g.,compact disks). When the information is ingested from the portablestorage device(s), the edge device 310 shares the information via thelocal cloud system 342 to conserve time and/or reduce costs associatedwith bandwidth usage. In some examples, the edge device 310 shares theinformation via the local cloud system 342 and uploads the informationonto the remote cloud system 302 based on criteria such as departmentaffiliation, traffic volume, referring source, availability of a patientportal and/or patient request, and/or other criteria.

A remote interpretation case arises when a clinician in a remote orrural geographic location requests an expert at the site 210 tointerpret a patient case. If the clinician and the site 210 areunaffiliated, the clinician shares the information via the remote cloudsystem 302 and not via the local cloud system 342.

A specialty treatment planning case arises when a patient case involvesa patient having a chronic disease that warrants planning services and atreatment plan from a specialized facility. The clinician 234 may sendthe patient to another healthcare facility that provides the planningservices and shares information related to the specialty treatmentplanning case to a clinician at the other healthcare facility via thecloud-based clinical information system 100. In some examples, theinformation is uploaded onto local cloud system 342 by the edge device310 if the healthcare facility is affiliated with the site 210 toconserve time and/or costs associated with bandwidth usage. In someexamples, the edge device 310 uploads the information related to thespecialty case onto the local cloud system 342 and the remote cloudsystem 302.

A review board case arises when the site 210 sends a patient case to areview board (e.g., a tumor review board) to enable members of thereview board to review the patient case. In some examples, the reviewboard employs an edge device to manage information traffic between themembers and traffic between the review board and the site 210. In someexamples, if the review board and the site are affiliated, the edgedevice 310 shares information related to the patient case via the localcloud system 342. A teaching case arises when the site 210 shares apatient case suitable for education or instruction to a healthcareentity for repository and/or to be viewed by students or healthcareprofessionals. In some examples, the edge device 310 anonymizes thepatient case and shares the patient case to affiliated healthcareentities via the local cloud system 342 and unaffiliated healthcareentities via the remote cloud system 302. In some examples, the edgedevice 310 distributes teaching cases between the remote cloud system302 and the local cloud system 342 based on contributors of the teachingcases, students to be taught based on the teaching case, type ofteaching case (e.g., modality, medical phenomena, procedure, etc.).

A research case arises when a researcher at the site 210 shares a casewith a colleague prior to submission of a medical paper or article. Insome examples, the edge device 310 shares the patient case to affiliatedhealthcare entities via the local cloud system 342 and unaffiliatedhealthcare entities via the remote cloud system 302.

FIG. 4 illustrates an example implementation of the example cloud-basedclinical information system 100 of FIG. 3. In the illustrated example,the remote cloud system 302 includes a user experience virtual machine400, an application services virtual machine 402, a zero footprintserver virtual machine 404, a streaming server virtual machine 406, animage storage and management virtual machine 408 and a plurality ofstorage devices 410, 412, 414, 416 in communication with an edge device418 and a viewer 420 (e.g., a workstation having a web browser) of asite 422 such as a hospital. In the illustrated example, a firewall 423controls information traffic between the edge device 418 and a PACS 424of the site 422 and between the edge device 418 and modalities 426 ofthe site 422.

In the illustrated example, functions of the user interface tier 304,the application services 330 and the identify management services 334are performed via the user experience virtual machine 400. Functions ofthe notification services 324, the event based services 326, 328 and thedata services 306 are performed via the example application servicesvirtual machine 402. The example zero footprint virtual machine 404 isused to perform functions of the user interface tier 304 such asrendering views or presentations, populating the views, providing usertools within the views, and/or other functions. The example streamingserver virtual machine 406 retrieves information from, for example, thestorage device 336, 338, 340 to populate views generated by the userinterface tier 304. The example image management and storage virtualmachine 408 is used to manage information flow between the storagedevices 336, 338, 340 and one or more of the edge device 418, theapplication services virtual machine 402, and the streaming servervirtual machine 406.

FIG. 5 illustrates another example implementation of the examplecloud-based clinical information system 100. In the illustrated example,a plurality of healthcare entities 500 are in communication with thecloud 300 via the internet 502. The example cloud 300 includes anapplication services virtual machine 504, a user experience virtualmachine 506, a zero footprint viewer virtual machine 508, informationmanagement and storage virtual machines 510, 512, a JMS virtual machine514, a DSP virtual machine 516 and a plurality of storage devices 518,520, 522. In some examples, functions of the example applicationservices 330 and/or the identity management services 334 such asverifying user credentials and/or managing rules related to receivingand sharing information via the credentials are performed via theapplication services virtual machine 504. In some examples, functions ofthe user interface tier 304, the application services 330 and theidentify management services 334 are performed via the user experiencevirtual machine 506. The example zero footprint virtual machine 508 isused to perform functions of the user interface tier 304 such asrendering views or presentations, populating the views, providing usertools within the views, and/or other functions. In some examples,functions of the notification services 324, the event based services326, 328 and the data services 306 are performed via the example JMSvirtual machine 514 and/or the DSP virtual machine 516. The exampleinformation management and storage virtual machines 510, 512 are used tomanage information flow within the example remote cloud system 302 ofFIG. 5.

Flow diagrams representative of example machine readable instructionsfor implementing the example cloud-based clinical system 100 are shownin FIGS. 6-8 and 15-22. In these examples, the machine readableinstructions include a program for execution by a processor such as theprocessor 2712 shown in the example processor platform 2700 discussedbelow in connection with FIG. 27. The program may be embodied insoftware stored on a tangible computer readable storage medium such as aCD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), aBlu-ray disk, or a memory associated with the processor 2712, but theentire program and/or parts thereof could alternatively be executed by adevice other than the processor 2712 and/or embodied in firmware ordedicated hardware. The computer program instructions particularlyconfigure and/or otherwise particularly program the processor, such asthe processor 2700. Further, although the example programs are describedwith reference to the flowcharts illustrated in FIGS. 6-8 and 15-22,many other methods of implementing the example cloud-based clinicalinformation system 100 may alternatively be used. For example, the orderof execution of the blocks may be changed, and/or some of the blocksdescribed may be changed, eliminated, or combined.

As mentioned above, the example processes of FIGS. 6-8 and 15-22 may beimplemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a tangible computer readable storagemedium such as a hard disk drive, a flash memory, a read-only memory(ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, arandom-access memory (RAM) and/or any other storage device or storagedisk in which information is stored for any duration (e.g., for extendedtime periods, permanently, for brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm tangible computer readable storage medium is expressly defined toinclude any type of computer readable storage device and/or storage diskand to exclude propagating signals and to exclude transmission media. Asused herein, “tangible computer readable storage medium” and “tangiblemachine readable storage medium” are used interchangeably. Additionallyor alternatively, the example processes of FIGS. 6-8 and 15-22 may beimplemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a non-transitory computer and/ormachine readable medium such as a hard disk drive, a flash memory, aread-only memory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device or storage disk inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information). As used herein, the termnon-transitory computer readable medium is expressly defined to includeany type of computer readable storage device and/or storage disk and toexclude propagating signals and to exclude transmission media. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended.

FIG. 6 illustrates a flow diagram of workflow 600 for a healthcareentity to register with the example cloud-based clinical informationsystem 100. In some examples, the healthcare entity registers with theexample cloud-based clinical information system 100 to create a profileor persona for use with the cloud-based information system 100 and/oracquire credentials associated with one or more of the entity types. Inthe illustrated example, the healthcare entity selects one of aplurality of registration paths 600, 602, 604, 606, 608 corresponding toa respective one of a plurality of entity types. The example workflow600 of FIG. 6 includes clinical registration 600, patient registration602, group registration 604, site registration 606 and communityregistration 608.

At block 610, data is collected based on the one of the registrationpaths 600, 602, 604, 606, 608 selected by the healthcare entity. Forexample, a clinician registering with the example cloud-based clinicalinformation system 100 may input information such as, name, address,title, phone number, pager number, license number, email address,preferred notification method, group affiliation, site affiliation,clinician identification (e.g., user name) and password and/or otherinformation. In some examples, the clinician consents to terms of use ofthe example cloud-based clinical information system 100, electronicallyexecutes business associate agreements, protected health informationagreements and/or other agreements and/or contracts.

A group registering with the example cloud-based clinical informationsystem 100 may input information such as group name, group address,group administrator information (e.g., name, address, title, phonenumber, email address, username and password, and/or other information)and/or other information. In some examples, the group consents to termsof use of the example cloud-based clinical information system 100,electronically executes business associate agreements, protected healthinformation agreements and/or other agreements and/or contracts. In someexamples, the group inputs information related to affiliations withsites and/or other healthcare entities.

A site registering with the example cloud-based clinical informationsystem 100 may input information such as site name, site address,account and/or billing information, site administrator information,and/or other information. In some examples, the site consents to termsof use of the example cloud-based clinical information system 100,electronically executes business associate agreements, protected healthinformation agreements and/or other agreements and/or contracts. In someexamples, the site inputs information related to affiliations with otherhealthcare entities. In some examples, the site also inputs informationrelated to local information systems employed by the site. For example,the site may input information related to PACS that are in communicationwith an edge device (e.g., the edge device 310).

In some examples, a community is registered via an administrator of theexample cloud-based clinical information system 100. For example, theadministrator of the cloud-based clinical information system 100 mayregister a community based on a request from business and/or commercialleaders in a geographic region and/or a subject matter area. In someexamples, the administrator inputs information related to the communityto register the community such as a name and/or contact information ofthe administrator, business and/or commercial leader contact informationand/or other information.

A patient registering with the example cloud-based clinical informationsystem 100 inputs information related to the patient such as name,address, contact information, username, password and/or otherinformation. In some examples, the patient consents to terms of use ofthe example cloud-based clinical information system 100 and/or otheragreements and/or contracts.

At block 612, the cloud-based clinical information system 100facilitates verification of the data input by the healthcare entitiesregistering with the example cloud-based clinical information system100. For example, the cloud-based clinical information system 100 mayverify information input by a clinician by comparing the informationinput by the clinician to information stored in a database employed bythe example cloud-based clinical information system 100. In someexamples, information input by a group is verified by an administratorof a site employing the example cloud-based clinical information system100. In some examples, an administrator verifies information input by acommunity. In other examples, information is verified in other ways.

At block 614, agreements electronically executed by the healthcareentities registering with the example cloud-based clinical informationsystem are stored in a secure archive 616. If the information input byone of the healthcare entities is verified at block 618, an acceptancenotification is communicated (e.g., via email) to the healthcare entityat block 620, and the healthcare entity is registered with the examplecloud-based clinical information system 100. Thus, the healthcare entitymay access and use the example cloud-based clinical information system100. If the information is not verified, a rejection notification iscommunicated to the healthcare entity at block 622, and the healthcareentity is not registered. In some examples, the rejection notificationincludes an explanation indicating why the information was not verified.

FIG. 7 illustrates a flow diagram of an example workflow 700 to enroll afirst healthcare entity with a second healthcare entity. Once the firsthealthcare entity is registered with the example cloud-based clinicalinformation system 100 (e.g., using the example workflow 600 of FIG. 6),the first healthcare entity may access and use the cloud-based clinicalinformation system 100. However, to access information from the secondhealthcare entity, the first healthcare entity enrolls with the secondhealthcare entity. In the illustrated example, enrollment involvesrequesting membership with the second healthcare entity and receivingapproval from the second healthcare entity.

At block 702, the first healthcare entity applies for membership withthe second healthcare entity. In some examples, the first healthcareentity applies via a user interface generated by the example cloud-basedclinical information system 100. In some examples, the user interfaceenables the first healthcare entity to search for the second healthcareentity via a directory. The first healthcare entity may then select thesecond healthcare entity to apply for membership with the secondhealthcare entity. In some examples, the first healthcare entity mayrequest privileges to one or more local information systems of thesecond healthcare entity. For example, if the first healthcare entity isa clinician, the first healthcare entity may request Promote-To-PACSprivileges of a PACS of the second healthcare entity.

In some examples, when the first healthcare entity applies formembership with the second healthcare entity, the cloud-based clinicalinformation system 100 determines if a business and/or legal agreementexists between the first healthcare entity and the second healthcareentity. For example, the cloud-based clinical information system 100determines if the first healthcare entity and the second healthcareentity are affiliated by determining if an agreement is stored in adatabase employed by the example cloud-based clinical information system100. If the first healthcare entity and the second healthcare entity arenot affiliated, the first healthcare entity is provided with anagreement and/or terms of use of the second healthcare entity via thecloud-based clinical information system 100. The agreement may begenerated by the example cloud-based clinical information system 100and/or the second healthcare entity. In some examples, the agreementand/or terms of use governs and/or determines rules for the firsthealthcare entity to access and/or share information accessible from thesecond healthcare entity via the cloud-based clinical information system100. For example, the agreement and/or terms of use may specify that thefirst healthcare entity may only use information from the secondhealthcare entity in predetermined ways and/or for predeterminedpurposes. In some examples, the agreement and/or terms of use governswhich healthcare entities the first healthcare entity may shareinformation with via the cloud-based clinical information system 100.For example, the agreement and/or terms of use may enable the firsthealthcare entity to refer patients under the care of the secondhealthcare entity to predetermined healthcare entities via thecloud-based clinical information system 100 while preventing the firsthealthcare entity from referring patients to healthcare entitiesunaffiliated with the second healthcare entity via the cloud-basedclinical information system 100. In some examples, the examplecloud-based clinical information system 100 stores the terms of useand/or the agreements and sets or writes rules for the first healthcareentity to access and share information via the cloud-based informationsystem 100 based on the agreements and/or terms of use.

In some examples, the cloud-based clinical information system 100enables the first to enroll with only predetermined healthcare entitytypes based on the example hierarchal organization scheme 200 of FIG. 2.For example, if the first healthcare entity is registered as aclinician, the first healthcare entity may enroll with groups, sites,IDNs and communities. However, the first healthcare entity may notenroll with patients. In another example, if the first healthcare entityis registered as a site, the first healthcare entity may enroll withIDNs and communities but not with clinicians.

Once the first healthcare entity applies for membership with the secondhealthcare entity at block 702, the cloud-based clinical informationsystem 100 notifies the second healthcare entity. In some examples, thecloud-based clinical information system 100 queues an application of thefirst healthcare entity for membership in a worklist of the secondhealthcare entity and sends an email to an administrator of the secondhealthcare entity to notify the administrator of the application. Thesecond healthcare entity may then review the application and approveand/or reject the application. At block 706, the first healthcare entityis notified of the decision of the second healthcare entity. If thesecond healthcare entity approved the application, the first healthcareentity may access information from the second healthcare entity via thecloud-based clinical information system 100.

FIG. 8 illustrates a flow diagram of an example user interface workflow800 disclosed herein. In the illustrated example, at block 802, a usermay access a user interface generated via the example cloud-basedclinical information system 100 via a web browser and securely log-in tothe cloud-based clinical information system 100 using a username andpassword input during registration (FIG. 6) of a healthcare entityassociated with the user. In some examples, if the user is associatedwith two entity types (e.g., the user may be a clinician plus apatient), the user selects one of the two entity types at block 804.Once the user logs in and has access to the user interface, the user mayuse the user interface to perform a plurality of actions via thecloud-based clinical information system 100. In the illustrated example,the user may view a network at block 806, receive information from ahealthcare entity at block 808, send information to a healthcare entityat block 810, send history (e.g., patient information history,transaction history, and/or other histories) to a healthcare entity atblock 812, view reports at block 814, manage an account of the user withthe cloud-based clinical information system 100 at block 816, performadministration tasks if the user is a healthcare entity administrator atblock 818 and/or perform other actions.

For example, once a first healthcare entity is registered with theexample cloud-based clinical information system 100 and enrolled with asecond healthcare entity, the first healthcare entity may employ theexample cloud-based clinical information system to send information tothe second healthcare entity via the cloud-based clinical informationsystem 100 and receive information from the second healthcare entity viathe cloud-based clinical information system. For example, the firsthealthcare entity may upload messages, documents, images (e.g., x-rays,etc.) and/or other information onto the remote cloud system 302 to beviewed and/or downloaded by the second healthcare entity. In someexamples, the first healthcare entity may share information from a localinformation system such as a DICOM system or a PACS via the cloud-basedclinical information system 100. In some examples, the healthcare entitymay share information from a CD or file stored on a local workstation.In some examples, the healthcare entity may employ a one-time shareoption to share information via the cloud-based clinical informationsystem 100 with a healthcare entity that is not registered with thecloud-based clinical information system 100. In some examples a historymay be shared via the example cloud-based clinical information system100. In some examples, the history includes information of patientspreviously treated by the healthcare entity, accessed by the healthcareentity, shared by the healthcare entity and/or any other information.

As described above, information may also be received via the examplecloud-based clinical information system 100. In the illustrated example,information stored in the remote cloud system 302 may be accessed viaemail and/or via a portal. For example, a user may receive an emailincluding a URL link to information accessible via the remote cloudsystem 302 (e.g., sent by a healthcare entity), and the user may employa web browser to open and display the information. In some examples, theuser may log into the cloud-based clinical information system 100 andview the information via a user interface (FIGS. 9-11) such as a zerofootprint viewer. In some examples, the information may be downloadedonto a local computer. In some examples, the cloud-based clinicalinformation system 100 ingests data from a portable storage device(e.g., a CD, a thumb drive, and/or any other portable storage device), alocal computer, an information system and/or any storage device.

Example user interfaces that may be used to implement the examplecloud-based clinical information system 100 and the example workflows700 and 800 of FIGS. 7-8 are illustrated in FIGS. 9-10. FIG. 9illustrates an example user interface 900 that may be generated via aweb browser and accessed via a secure login by a user (e.g., anadministrator of a healthcare entity). In the illustrated example, theuser interface 900 lists healthcare entities 902 (e.g., clinicians,groups, sites, communities and/or other healthcare entities) that theuser may send information to and/or receive information from via theexample cloud-based clinical information system 100 (e.g., the user isenrolled with the healthcare entities 902 and/or the healthcare entities902 are enrolled with the user). The example user interface 900 alsoenables the user to send messages to the healthcare entities 902, whichmay include information retrieved from a local information system (e.g.,PACS). In some examples, the user interface 900 enables the user to sortthe healthcare entities 902 based on entity type and/or other in otherways (e.g., alphabetically, via tags, by geographic location, byindustry, by department, by practice type and/or other ways). In someexamples, the user may select a healthcare entity listed on the userinterface 900 to view communication between the user and the healthcareentity, view information shared between the user and the healthcareentity, enable the user to share information with the healthcare entityvia the cloud-based clinical information system 100, and/or performother actions. For example, the user may select one of the healthcareentities 900 and view a medical image sent to the user by the one of thehealthcare entities 900 using a zero footprint viewer.

In the illustrated example, the user interface 900 enables the user torequest enrollment and/or enroll with other healthcare entities. Forexample, the user may view a directory of healthcare entities and selectone or more of the healthcare entities to request enrollment with thehealthcare entity(ies). The user interface 900 may automaticallypopulate portions of an application to be submitted by the user toenroll with the healthcare entity with information such as, name, typeof entity, geographic information, and/or other information related tothe user requesting enrollment. In some examples, the user may searchfor one or more healthcare entities via the directory based on practicetype or specialty (e.g., radiology, pediatrics, etc.), geographiclocation, name, and/or other characteristic(s) and/or in other ways. Insome examples, the directory includes healthcare entities that areregistered with the example cloud-based clinical information system butare not affiliated with the user. Thus, the user interface 900 enablesthe user to expand a network of healthcare professions for referrals,medical expertise, treatment options, etc.

FIG. 10 illustrates another example user interface 1000 disclosed hereinthat may be used to implement the example cloud-based clinicalinformation system 100. The example user interface of FIG. 10 may begenerated via a web browser and accessed via a secure login by a user(e.g., an administrator of a healthcare entity). In the illustratedexample, the user interface 1000 lists of healthcare entities includingclinicians 1002 that are members of sites 1004 that are members ofintegrated delivery networks (IDNs) 1006. In some examples, the user maybe enrolled with the clinicians 1002 but not the sites 1004 or the IDNs1006. In some examples, the user interface 1000 enables the user torequest enrollment with the sites 1004, the IDNs 1006 and/or members ofthe sites 1004 (e.g., clinicians) and/or the IDNs (e.g., other sites).

FIG. 11 illustrates an example user interface 1100 that may be used toimplement the example cloud-based clinical information system 1100. Inthe illustrated example, the user interface 1100 enables the user toview an inbox 1101 listing one or more transactions 1102 (e.g.,information sent, information received, messages communicated, and/orany other transactions). In some examples, the transactions areorganized based on cases. For example, if the user is a clinician, acase may be transactions related to a patient under the care of theuser. The user may use the example user interface 1100 to view allcases, view cases created by the user, view cases received by the user,view cases shared by the user, view cases of a selected type, viewrelated cases, view draft cases, preview a case or information (e.g., byplacing a cursor over an icon representative of the case or theinformation) and/or view other types or categories of information. Insome examples, the user interface 1100 enables the user to create a newcase, share the new case with a healthcare entity via the cloud-basedclinical information system 100, adjust account settings, perform acontext-sensitive search (e.g., for cases, words in messages, names,etc.), run a report (e.g., analytics, benchmarking, and/or any type ofreport), perform administrative actions (e.g., change billinginformation of a site, etc.) and/or perform other actions and/or viewother information.

If the user selects one of the cases, the user interface 1100 maydisplay a history of the case. The history may include senders andrecipients of the case, rational(s) for sharing the case, forwarding andreplying logs, comments related to the case, studies and/or filesassociated with the cases and/or other information (e.g., dates, times,and/or any other information). In some examples, the interface 1100enables the user to add information to the case (e.g., comments,reports, analysis, and/or other information), forward the case to one ormore healthcare entities (e.g., one of the healthcare entities 902,1002, 1006, 1008 listed in the user interfaces of FIGS. 9-10), view caseinformation (e.g., medical images, reports, patient information, and/orother information), request information related to the case from otherhealthcare entities, decline a referral, accept a referral and/orperform other actions.

In some examples, the user interface 1100 enables users to collaborateregarding a case. For example, a first clinician treating a patient maysend a case to a second clinician. The second clinician may view patientinformation such as medical images, reports, case history, commentsprovided by the first clinician and/or other information via the userinterface 1100. The second clinician may analyze the patient informationand generate a report including, for example, a clinical analysis, whichthe second clinician sends to the first clinician via the remote cloudsystem 302. The cloud-based clinical information system 100 attaches thereport to the case, and the first clinician may view the case includingthe report from the second clinician via the user interface 1100. Thefirst clinician may then use the report to treat the patient.

In some examples, information is accessible via the user interface 1100for a predetermined amount of time. For example, if the user of theinterface 1100 receives a medical image to analyze from a healthcareentity via the cloud-based clinical information system 100, the medicalimage may be accessed and viewed via the interface 1100 for thirty daysfrom a day of receipt and/or a day on which the medical image was firstviewed. After thirty days, the user may no longer be able to view themedical image unless the healthcare entity re-sends the medical image.In some examples, the user interface 1100 provides a zero footprintviewer and automatically populates the viewer with information. Forexample, if the healthcare entity sends the user the medical imagerelated to a patient, the user interface 1100 may present the image andinformation related to the patient (e.g., name, date the medical imagewas captured, etc.) via the zero footprint viewer.

FIG. 12 illustrates the example cloud-based clinical information system100 in communication with a first healthcare entity 1200 and a secondhealthcare entity 1202. In the illustrated example, the cloud-basedclinical information system 100 is integrated with a first localinformation system 1204 and a second local information system 1206 of asecond healthcare entity 1202. In the illustrated example, the secondhealthcare entity 1202 is a site such as a care center. In theillustrated example, a first healthcare entity 1200 such as a clinic mayrefer a patient to the second healthcare entity 1202 via the cloud-basedclinical information system 100. For example, the first healthcareentity 1200 may use the example user interfaces 900, 1000, 1100 of FIGS.9-11 to upload information related to the patient (e.g., demographicinformation such as name, age, etc., medical information such asreports, images such as x-rays and/or other information) onto thecloud-based clinical information system.

In the illustrated example, an edge device 1208 is employed by theexample second healthcare entity 1202 to facilitate communicationbetween the first local information system 1204 (e.g., PACS) and theremote cloud system 302 and between the second clinical informationsystem 1202 (e.g., a RIS/EMR system) and the cloud. In other examples,more than one edge device may be employed. The example remote cloudsystem 302 of FIG. 12 includes a cloud application 1210, records manager1211, an HL7 processor 1212, document and image storage devices 1214,and a healthcare information analytics engine 1216. As described ingreater detail below in conjunction with FIGS. 13-14, the example edgedevice 1208 and the remote cloud system 302 cooperate to automaticallygenerate patient and/or exam records in the first local informationsystem 1204 and/or the second local information system 1206 when thefirst healthcare entity 1200 refers the patient to the second healthcareentity 1202.

FIG. 13 illustrates an example workflow illustrating the examplecloud-based clinical information system 100 integrated with the firstlocal information system 1204 of the first healthcare entity of FIG. 12to automatically generate a patient record in the first localinformation system 1204. In the illustrated example, the first localinformation system 1204 is a PACS employing DICOM protocol. Otherexamples may use other types of local information systems and/orprotocols.

In the illustrated example, the first healthcare entity 1200 refers apatient to the second healthcare entity 1202 by uploading a patientreferral order including healthcare information such as images, reports,documents, and/or other information into the document and image storagedevices 1214 of the remote cloud system 302 via the cloud application1210. In some examples, the cloud-based clinical information system 100notifies the second healthcare entity 1202 (e.g., via an email) of thereferral and enables the second healthcare entity 1202 to accept ordecline the referral (e.g., via the user interfaces 900, 1000, 1100 ofFIGS. 9-11).

The healthcare information analytics engine 1216 of the examplecloud-based clinical information system 100 analyzes the case data todetermine, for example, that the second healthcare entity 1202 is toreceive the case data by, for example, digesting predeterminedparameters and/or data. The example cloud-based clinical informationsystem 100 instructs the edge device 1208 to communicate with the firstlocal information system 1204 and automatically generate a patientrecord (e.g., an exam record) and/or attach the healthcare informationto an existing patient record (e.g., a record previously generated inthe first local information system 1204, for example, if the patient hasbeen previously treated via the second healthcare entity 1202). Theexample cloud-based clinical information system 100 then sends thehealthcare information via, for example, a Secure DICOM datatransmission to the edge device 1208, and the edge device 1208 forwardsthe healthcare information to the first local information system 1204.

In some examples, the healthcare information analytics engine 1216determines which portions of the healthcare information such as amedical image is to be stored in the first local information system1204, and the records manager 1211 separates, tags and/or communicatesthe portion of the healthcare information to the edge device 1208 viathe document and storage devices 1214. The example local informationsystem 1200 then automatically attaches the portion of the healthcareinformation to the patient record. Thus, before and/or when the examplepatient is transported and/or arrives at the second healthcare entity1202 for treatment, the patient record is available to healthprofessionals of the second healthcare entity 1202.

FIG. 14 illustrates an example workflow illustrating the examplecloud-based clinical information system 100 integrated with the firstlocal information system 1204 and the second local information system1206 of the first healthcare entity of FIG. 14 to automatically generatepatient records in the first local information system 1204 and/or thesecond local information system 1204. In the illustrated example, thefirst local information 1204 is the PACS employing the DICOM protocoland the second local information system 1206 is a radiology informationsystem (RIS) and/or electronic medical records (EMR) system employingHL7 protocol. Other examples employ other types of local informationsystems and/or protocols.

In some examples, the first healthcare entity 1200 refers a patient tothe second healthcare entity 1202 by uploading a patient referral orderincluding, for example, healthcare information such as images, reports,documents, and/or other information into the document and storagedevices 1214 of the remote cloud system 302 via the cloud application1210. In the illustrated example, the cloud-based clinical informationsystem 100 automatically retrieves healthcare information related to thepatient uploaded onto the remote cloud system 302 from other healthcareentities employing the cloud-based clinical information system 100 toenable the second healthcare entity 1202 to view and/or store acomprehensive and/or cohesive collection of information related to thepatient. For example, the records manager 1211 may search or query thedocument and image storage device 1214 for healthcare informationrelated to the patient. In some examples, the edge device 1208 requestsHL7 order transactions and/or PACS data related to the patient, and therecords manager 1211 collects HL7 order transactions related to thepatient from other healthcare entities employing the example cloud-basedclinical information system 100. In some examples, the cloud-basedclinical information system 100 uploads the HL7 order transactions intothe remote cloud system 302. Healthcare information from the HL7 ordertransactions is matched via fuzzy logic via the healthcare informationanalytics engine 1216. In some examples, the remote cloud system 302conducts one or more DICOM queries to the first local information system1204 via the edge device 1208. The example healthcare informationanalytics engine 1216 of the cloud-based clinical information system 100analyzes the healthcare information included in the patient referralorder, the HL7 order transactions and/or PACS data to determine, forexample, which one(s) of the first local information system 1204 and/orthe second local information system 1206 is to generate patient recordsto be populated by one or more portions of the healthcare information.

The example cloud-based clinical information system 100 instructs theedge device 1208 to communicate with the first local information system1204 and/or the second local information system 1206 to automaticallygenerate patient records and/or attach the healthcare information toexisting patient and/or exam records. The example cloud-based clinicalinformation system 100 then sends the healthcare information to the edgedevice 1208, and the edge device 1208 forwards the healthcareinformation to the first local information system 1204 and/or the secondlocal information system 1206. The example local information system 1200and/or the example second local information system 1206 automaticallyattaches the healthcare information to the patient records. Thus, beforeand/or when the example patient is transported and/or arrives at thesecond healthcare entity 1202 for treatment, the patient records areavailable to health professionals of the second healthcare entity 1202employing the first local information system 1204 and/or the secondlocal information 1202.

In some examples, the cloud-based clinical information system 100updates the patient records of the first clinical information system1200 and/or the second clinical information system 1204 when informationrelated to the patient is generated by other healthcare entitiesemploying the cloud-based clinical information system 100. Thus, if thesecond healthcare entity 1204 subsequently refers the patient to a thirdhealthcare entity, patient information (e.g., reports, images, and/orany other information) generated by the third healthcare entity may beautomatically uploaded into the remote cloud system 302 and attached tothe patient records of the first local information system 1204 and/orthe second local information system 1206.

While an example manner of implementing the cloud-based clinicalinformation system 100 of FIG. 1 is illustrated in FIGS. 3-5 and 12-14,one or more of the elements, processes and/or devices illustrated inFIGS. 3-5 and 12-14 may be combined, divided, re-arranged, omitted,eliminated and/or implemented in any other way. Further, the examplearchitecture 300, the example remote cloud system 302, the exampleweb/user interface tier 304, the example service tier 306, the examplestorage tier 308, the example edge device 310, the example localinformation systems 312, 314, the example notification services 316, theexample event based services 318, 320, the example, application services322, the example data services 324, the example identity managementservices 326, the example storage devices 328, 330, the example virtualmachines 400, 402, 404, 406, 408, the example storage devices 410, 412,414, 416, the example edge device 418, the example site 424, the examplePACS 424, the example modalities 426, the example healthcare entities500, the example internet 502, the example virtual machines 504, 506,508, 510, 512, 514, 516, the example storage devices 518, 520, 522, theexample first local information system 1204, the example second localinformation system 1206, the example second healthcare entity 1202, theexample first healthcare entity 1200, the example edge device 1208, theexample cloud application 1210, the records manager 1211, the exampleHL7 processor 1212, the example image storage devices 1214, the examplehealthcare information analytics engine 1216 and/or, more generally, theexample cloud-based clinical information system 100 of FIG. 1 may beimplemented by hardware, software, firmware and/or any combination ofhardware, software and/or firmware. Thus, for example, any of theexample architecture 300, the example remote cloud system 302, theexample web/user interface tier 304, the example service tier 306, theexample storage tier 308, the example edge device 310, the example localinformation systems 312, 314, the example notification services 316, theexample event based services 318, 320, the example, application services322, the example data services 324, the example identity managementservices 326, the example storage devices 328, 330, the example virtualmachines 400, 402, 404, 406, 408, the example storage devices 410, 412,414, 416, the example edge device 418, the example site 424, the examplePACS 424, the example modalities 426, the example healthcare entities500, the example internet 502, the example virtual machines 504, 506,508, 510, 512, 514, 516, the example storage devices 518, 520, 522, theexample first local information system 1204, the example second localinformation system 1206, the example second healthcare entity 1202, theexample first healthcare entity 1200, the example edge device 1208, theexample cloud application 1210, the records manager 1211, the exampleHL7 processor 1212, the example image storage devices 1214, the examplehealthcare information analytics engine 1216 and/or, more generally, theexample cloud-based clinical information system 100 of FIG. 1 could beimplemented by one or more analog or digital circuit(s), logic circuits,programmable processor(s), application specific integrated circuit(s)(ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)). When reading any of theapparatus or system claims of this patent to cover a purely softwareand/or firmware implementation, at least one of the example architecture300, the example remote cloud system 302, the example web/user interfacetier 304, the example service tier 306, the example storage tier 308,the example edge device 310, the example local information systems 312,314, the example notification services 316, the example event basedservices 318, 320, the example, application services 322, the exampledata services 324, the example identity management services 326, theexample storage devices 328, 330, the example virtual machines 400, 402,404, 406, 408, the example storage devices 410, 412, 414, 416, theexample edge device 418, the example site 424, the example PACS 424, theexample modalities 426, the example healthcare entities 500, the exampleinternet 502, the example virtual machines 504, 506, 508, 510, 512, 514,516, the example storage devices 518, 520, 522, the example first localinformation system 1204, the example second local information system1206, the example second healthcare entity 1202, the example firsthealthcare entity 1200, the example edge device 1208, the example cloudapplication 1210, the records manager 1211, the example HL7 processor1212, the example image storage devices 1214, the example healthcareinformation analytics engine 1216 and/or, more generally, the examplecloud-based clinical information system 100 of FIG. 1 is/are herebyexpressly defined to include a tangible computer readable storage deviceor storage disk such as a memory, a digital versatile disk (DVD), acompact disk (CD), a Blu-ray disk, etc. storing the software and/orfirmware. Further still, the example cloud-based clinical informationsystem 100 may include one or more elements, processes and/or devices inaddition to, or instead of, those illustrated in FIG. 1, and/or mayinclude more than one of any or all of the illustrated elements,processes and devices.

The example program 1500 of FIGS. 15-17 may be executed to integrate thecloud-based clinical information system 100 with one or more localinformation systems of a healthcare entity. For example, the program1500 of FIGS. 15-17 may be executed to automatically attach healthcareinformation from the cloud-based clinical information system 100 to oneor more medical records stored in the local information system(s) of thehealthcare entity. In some examples, the program 1500 may be executed toautomatically generate new patient records in the local informationsystem(s) of the healthcare entity if the local information system(s)does not include an existing patient record and then automaticallyattach the healthcare information to the new patient records. Thus, whena first healthcare entity refers a patient to a second healthcare entityvia the cloud-based clinical information system 100, the firsthealthcare entity may upload healthcare information onto the cloud-basedclinical information system 100, and the cloud-based clinicalinformation system 100 automatically stores the healthcare informationonto the local information system(s) of the second healthcare entity.

The program 1500 of FIGS. 15-17 begins when the example healthcareinformation analytics engine 1216 of FIG. 12 receives a patient referralorder in the cloud-based clinical information system 100 from the firsthealthcare entity 1200 (block 1502). In some examples, the patientreferral order is uploaded onto and/or received by the cloud-basedclinical information system 100 via a web-based application employing apublic network such as the internet. In some examples, the patientreferral order includes first healthcare information related to apatient. The first healthcare information may include, for example, oneor more medical images (e.g., an x-ray image, an Mill image, etc.),medical reports, contact and/or demographic information of the patientand/or any other information related to the patient.

The example healthcare information analytics engine 1216 analyzes thepatient referral order to determine that the second healthcare entity1202 is to receive the first healthcare information to, for example,treat the patient based on the patient referral order (block 1504). Insome examples, the cloud application 1210 communicates a notification tothe second healthcare entity 1202 via the edge device 1208 located at afacility associated with the second healthcare entity 1202. For example,the notification services 324 may generate and communicate (e.g., viaemail, text message and/or any other way) notifications to a user of theexample cloud-based clinical information system 100 associated with thesecond healthcare entity 1202. For example, if the patient referralorder specifies a clinician employed by the second healthcare entity1202 to treat the patient, the notification services 324 may generateand communicate a text message to a phone associated with the clinician.In some examples, the notification includes a link accessible via a webbrowser or a web application that enables the user to view the patientreferral order and accept or decline the referral. In some examples, ifthe cloud-based clinical information system 100 receives an acceptancefrom the second healthcare entity, the instructions continue at block1516.

The example healthcare information analytics engine 1216 determines ifthe first local information system 1204 includes a first existingpatient record associated with the patient (block 1506). For example,the cloud-based clinical information system 100 may query the firstlocal information system 1204 via the edge device 1208 to determine ifthe first local information system 1204 includes the first existingpatient record. If the first local information system 1204 includes thefirst existing patient record, the records manager 1211 communicates afirst portion of the first healthcare information to the edge device1208 of the second healthcare entity 1202 (block 1508). In someexamples, the records manager 1211 communicates the first portion of thefirst healthcare information by retrieving the first portion of thefirst healthcare information from the document and image storage device1214 and sending the first portion of the first healthcare informationto the edge device 1208 via, for example, a Secure DICOM datatransmission. The records manager 1211 commands the edge device 1208 toautomatically attach the first portion of the first healthcareinformation to the first existing patient record (block 1510). Thus, thefirst existing patient record may be automatically updated with thefirst portion of the first healthcare information.

In some examples, the healthcare information analytics engine 1216determines if and/or which portion(s) of the first healthcareinformation such as a medical image is to be communicated to the edgedevice 1208 and/or attached to the first existing patient record basedon one or more types of information employed by the first localinformation system 1204. For example, if the first local informationsystem 1204 is a PACS, the healthcare information analytics engine 1216may determine that medical images and information relating to themedical images in the first healthcare information is to be communicatedto the edge device 1208 to be attached to the existing patient record inthe first local information system 1204.

If the first local information system 1204 does not include the firstexisting patient record associated with the patient (block 1506), therecords manager 1211 commands the edge device 1208 to automaticallygenerate a first new patient record in the first local informationsystem 1204 (block 1512). The example records manager 1211 communicatesthe first portion of the first healthcare information to the edge device1208 (block 1514) and commands the edge device 1208 to automaticallyattach the first portion of the first healthcare information to thefirst new patient record. The example edge device 1208 then generatesthe first new patient record and attaches the first portion of the firsthealthcare information to the first new patient record.

In the illustrated example, the instructions 1500 continue when thehealthcare information analytics engine 1216 determines if a secondportion of the first healthcare information is to be stored in thesecond local information system 1206 of the second healthcare entity1202. For example, if the second local information system 1206 is aradiology information system (RIS) and/or an electronic medical records(EMR) system, the healthcare information analytics engine 1216determines if any portions of the first healthcare information includeinformation that is to be stored in an MS or an EMR system. In someexamples, the first local information system 1204 and the second localinformation system 1206 employ different secure protocols such as aDICOM protocol and an HL7 protocol, respectively. If the second portionof the first healthcare information is to be stored in the second localinformation system 1206, the example healthcare information analyticsengine 1216 determines if the second local information system 1206 ofthe second healthcare entity 1202 includes a second existing patientrecord associated with the patient (block 1602). If the second localinformation system 1206 includes the second existing patient record, therecords manager 1211 communicates the second portion of the firsthealthcare information to the edge device 1208 (block 1604) and commandsthe edge device 1208 to automatically attach the second portion of thefirst healthcare information to the second existing patient record(block 1606).

If the second local information system 1206 determines that the secondlocal information system does not include the second existing patientrecord associated with the patient (block 1602), the records manager1211 commands the edge device 1208 to automatically generate a secondnew patient record in the second local information system 1206 (block1608), communicates the second portion of the first healthcareinformation to the edge device (block 1610), and commands the edgedevice 1208 to automatically attach the second portion of the firsthealthcare information to the second new patient record (block 1612).The example edge device 1208 then communicates with the example secondlocal information system 1206 to automatically generate the second newpatient record, and the edge device 1208 attaches the second portion ofthe first healthcare information to the second new patient record.

Once the records manager 1211 commands the edge device 1208 toautomatically attach the second portion of the first healthcareinformation to the second existing patient record (block 1606) or thesecond new patient record (block 1612), or if the second portion of thefirst healthcare information is not to be stored in the second localinformation system 1206 (block 1600), the example instructions 1600continue at block 1700 of FIG. 17. The healthcare information analyticsengine 1216 determines if second healthcare information related to thepatient is stored on the cloud-based clinical information system 100(block 1700). For example, the patient may have been treated by one ormore other healthcare entities employing the example cloud-basedclinical information system 100, and the one or more other healthcareentities may have uploaded the second healthcare information onto thecloud-based clinical information system 100. In some examples, thehealthcare information analytics engine 1216 monitors healthcareinformation uploaded onto the cloud-based clinical information system100 by the one or more other healthcare entities and determines if thehealthcare information is related to the patient via, for example, fuzzylogic.

If the second healthcare information is not stored on the cloud-basedclinical information system 100, the example instructions 1500 end. Ifthe second healthcare information is stored on the cloud-based clinicalinformation system 100, the healthcare information analytics engine 1216determines if a portion of the second healthcare information is to beattached to one or more of the first new patient record, the second newpatient record, the first existing patient record, and/or the secondexisting patient record (block 1702). In some examples, the healthcareinformation analytics engine 1612 determines if the second healthcareinformation is to be attached to the first new patient record, thesecond new patient record, the first existing patient record, and/or thesecond existing patient record based on a request from the edge device1208 for additional information related to the patient. For example, theedge device 1208 may communicates a request such as an HL7 order for thesecond healthcare information (e.g., additional healthcare information)related to the patient, and the healthcare information analytics engine1216 collects HL7 order transactions that include the second healthcareinformation from the cloud-based clinical information system 100 and/orcollects HL7 order transactions from local information systems of theone or more other healthcare entities. Based on the informationcollected and the local information systems 1204, 1206 employed by thesecond healthcare entity 1202, the healthcare information analyticsengine 1216 determines if a portion of the second healthcare informationis to be attached to the first new patient record, the second newpatient record, the first existing patient record, and/or the secondexisting patient record. In some examples, the healthcare informationanalytics engine 1216 determines if the portion of the second healthcareinformation is to be attached to the first new patient record, thesecond new patient record, the first existing patient record, and/or thesecond existing patient record by querying the first local informationsystem 1204 and/or the second local information system 1206.

If the portion of the second healthcare information is not to beattached to the first new patient record, the second new patient record,the first existing patient record, and/or the second existing patientrecord, the example instructions 1500 end. If the portion of the secondhealthcare information is to be attached to the first new patientrecord, the second new patient record, the first existing patientrecord, and/or the second existing patient record, the records manager1211 communicates the portion of the second healthcare information tothe edge device 1208 (block 1704) and commands the edge device 1208 toautomatically attach the portion of the second healthcare information tothe first new patient record, the second new patient record, the firstexisting patient record, and/or the second existing patient record.Thus, the example cloud-based clinical information system 100 may beused to collect and store a comprehensive and/or cohesive collection ofhealthcare information related to the patient.

The example instructions 1800 of FIGS. 18-20 may be executed to enablehealthcare entities to employ the cloud-based clinical informationsystem 100, manage contractual agreements between the healthcareentities and enable the healthcare entities to collaborate with eachother to treat patients. The example instructions 1800 of FIGS. 18-20begin when the cloud-based clinical information system 100 receives afirst selection from a first user to register a first healthcare entitywith the cloud-based clinical information system 100 as a first entitytype (block 1802). For example, the first user may employ a web browseror web-based application to input the first selection via a userinterface generated by the user interface tier 304 of the example remotecloud system 302.

In some examples, the cloud-based clinical information system 100enables the user to register the first healthcare entity as one of aplurality of entity types such as, for example, a patient, a clinician,a site, an integrated delivery network (IDN), a community and/or otherentity types. In some examples, the entity types are organizedhierarchically using, for example, the hierarchal organization scheme200 of FIG. 2. In some examples, each of the entity types is associatedwith respective sharing and access rights to information uploaded ontothe cloud-based clinical information system 100. For example, ahealthcare entity registered as a patient may access information on thepatient via the cloud-based clinical information system 100 from anyhealthcare entity employing the cloud-based clinical information system100 and share the information on the patient with any healthcareentities via the cloud-based clinical information system 100. However, ahealthcare entity registered as a clinician, for example, may onlyaccess healthcare information related to patients that the healthcareentity treated, is treating or is to treat. In some examples, ahealthcare entity registered as a site may access healthcare informationrelated to patients that have been or are under the care of thehealthcare entity. For example, if the healthcare entity is a hospitalregistered as the site, a user associated with the hospital may accesshealthcare information related to patients treated in the hospital.

The cloud-based clinical information system 100 registers the firsthealthcare entity with the cloud-based clinical information 100 as thefirst entity type based on the first selection (block 1804). The examplecloud-based clinical information system 100 assigns the first healthcareentity first sharing rights and first access rights to first healthcareinformation associated with the first healthcare entity based on thefirst healthcare entity being the first entity type (block 1806). Insome examples, the first healthcare information is information that isuploaded onto the cloud-based clinical information system 100 by thefirst healthcare entity, information uploaded onto the cloud-basedclinical information system 100 by other healthcare entities to sharethe information with the first healthcare entity and/or otherinformation.

The cloud-based clinical information system 100 receives an enrollmentrequest to enroll the first healthcare entity with a second healthcareentity registered with the cloud-based clinical information system 100(block 1808). In some examples, the second healthcare entity isregistered with the cloud-based clinical information system 100 as asecond entity type the same as or different than the first entity type.In some examples, a contractual agreement related to the firsthealthcare information and/or second healthcare information associatedwith the second healthcare entity is uploaded onto the cloud-basedclinical information system 100 by the first healthcare entity or thesecond healthcare entity. The second healthcare information may be, forexample, information uploaded onto the cloud-based clinical informationsystem 100 by the second healthcare entity, stored in one or more localinformation systems (e.g., PACS, an RIS/EMR system, etc.) of the secondhealthcare entity and/or other information. The cloud-based clinicalinformation system 100 stores the contractual agreement between thefirst healthcare entity and the second healthcare entity in thecloud-based clinical information system 100 (block 1810).

The cloud-based clinical information system 100 enrolls the firsthealthcare entity with the second healthcare entity based on thecontractual agreement and a second selection of an access rule input bya second user associated with the second healthcare entity (block 1900).For example, once the first healthcare entity requests enrollment (e.g.,applies for membership) with the second healthcare entity, thecloud-based clinical information system 100 notifies the secondhealthcare entity. In some examples, the cloud-based clinicalinformation system 100 queues an enrollment application of the firsthealthcare entity in a worklist of the second healthcare entity andsends an email to the second user (e.g., an administrator of the secondhealthcare entity) to notify the second user of the application. Thesecond user may then review the application and approve and/or rejectthe application. In some examples, if the second user accepts theapplication, the second user may select the access rule that is togovern a scope of access of the first healthcare entity to the secondhealthcare information. For example, the access rule may enable thefirst healthcare entity to view the second healthcare information via aweb browser of a workstation in communication with the cloud-basedclinical information system but prevent the first healthcare entity fromdownloading the second healthcare information onto a local informationsystem of the first healthcare entity. In some examples, the access ruleenables the first healthcare entity to view and download the secondhealthcare information from the cloud-based clinical information system100. In some examples, the access rule enables the first healthcareentity to access a local information system of the second healthcareentity via the cloud-based clinical information system to retrieve thesecond healthcare information. In other examples, the access rulegoverns the scope of the access of the first healthcare entity to thesecond healthcare information in other ways. Based on the secondselection of the access rule, the cloud-based clinical informationsystem 100 assigns the access rule to the first healthcare entity (block1902).

In some examples, the second user inputs a third selection of a sharingrule for the first healthcare entity. In some examples, the sharing rulegoverns sharing of the second healthcare information via the cloud-basedclinical information system 100 by the first healthcare entity. Forexample, the sharing rule may enable the first healthcare entity toshare the second healthcare information with other healthcare entitiesspecified by the second healthcare entity via the cloud-based clinicalinformation system 100. In some examples, the sharing rule prevents thefirst healthcare entity from sharing the second healthcare informationwith other healthcare entities via the cloud-based clinical informationsystem 100. The cloud-based clinical information system 100 assigns thesharing rule to the first healthcare entity based on the third selection(block 1904). In the illustrated example, the cloud-based clinicalinformation system 100 enables the first healthcare entity to access andshare the second healthcare information from the cloud-based clinicalinformation system based on the access rule and the sharing rule,respectively (block 1906).

In the illustrated example, the cloud-based clinical information system100 receives a request from the first healthcare entity to share thesecond healthcare information with a third healthcare entity via thecloud-based clinical information system 100 (block 1908). For example,the first healthcare entity may send the request to enable the thirdhealthcare entity to access the second healthcare information to enablethe first healthcare entity to collaborate with the third healthcareentity to treat a patient. For example, the first healthcare entity maysend the request to enable the third healthcare entity to view thesecond healthcare information and provide a second opinion related tothe patient. As discussed above, in some examples, an ability of thefirst healthcare entity to share the second healthcare information withthe third healthcare entity is governed by the sharing rule selected bythe second user associated with the second healthcare entity. In theillustrated example, the cloud-based clinical information system 100enables the third healthcare entity to access the second healthcareinformation via the cloud-based clinical information system 100 (block2000). In some examples, the third healthcare entity enrolls with thefirst healthcare entity to enable the third healthcare entity to accessthe second healthcare information shared by the first healthcare entityvia the cloud-based clinical information system 100.

In the illustrated example, the third healthcare entity may view thesecond healthcare information via a web browser and/or a web-basedapplication providing a user interface generated via the cloud-basedclinical information system 100. In some examples, the third healthcareentity may generate information such as a message via the user interfaceand/or upload information (e.g., documents, medical images, etc.) to thecloud-based clinical information system 100 via the user interface. Inthe illustrated example, the cloud-based clinical information system 100attaches a message generated by the third healthcare entity to thesecond healthcare information (block 2002). In some examples, attachingthe message to the second healthcare information generates and/orupdates a case history of a patient. The example cloud-based clinicalinformation system 100 enables the first healthcare entity and thesecond healthcare entity to view the second healthcare information andthe message via the cloud-based clinical information system (block2004). Thus, the example first healthcare entity, the example secondhealthcare entity and the example third healthcare entity maycollaborate to generate the case history to facilitate treatment of thepatient.

In some examples, a business and/or contractual agreement between thefirst healthcare entity and the second healthcare entity may end orexpire, and the second healthcare entity may send an un-enrollmentrequest to the cloud-based clinical information system to prevent thefirst healthcare entity from subsequently accessing and sharinginformation associated with the second healthcare entity. Thecloud-based clinical information system 100 receives the un-enrollmentrequest to un-enroll the first healthcare entity from the secondhealthcare entity (block 2006) and un-enrolls the first healthcareentity from the second healthcare entity to prevent the first healthcareentity from accessing the second healthcare information via thecloud-based clinical information system 100 without altering the firstsharing and first access rights of the first healthcare entity (block2008). Thus, even after the first healthcare entity is un-enrolled withthe second healthcare entity, the first healthcare entity may continueto employ the cloud-based clinical information system 100 to collaboratewith other healthcare entities and access and share informationassociated with the first healthcare entity via the cloud-based clinicalinformation system 100.

The example instructions 2100 of FIGS. 21-22 may be executed toimplement an example hybrid cloud system that routs healthcareinformation and/or allocates computing tasks between, for example, thelocal information systems 312, 314, the local cloud system 342 and theremote cloud system 302 of FIG. 3. As described above in conjunctionwith FIG. 3, the remote cloud system 302 is accessible by a plurality ofhealthcare entities via a public network such as the internet. Thehealthcare entities may be unaffiliated with each other. For example,healthcare entities may be unaffiliated when no contractual or businessagreements exist between the healthcare entities. The example localcloud system 342 of FIG. 3 is implemented by the example edge device310. In some example, the local cloud system 342 is accessible only bythe first healthcare entity 210 and a plurality of healthcare entitiesaffiliated with the first healthcare entity via a private network suchas a local area network (LAN) or a virtual private network (VPN).Healthcare entities may be affiliated when a contractual or businessagreement or a legal relationship exists between the healthcareentities. For example, a second healthcare entity that is owned and/oroperated by the first healthcare entity may be affiliated with the firsthealthcare entity.

The example instructions 2100 begin when the example edge device 310monitors first healthcare information employed by the local informationsystem 312 (block 2102). For example, the edge device 310 mayperiodically query the local information system 312 to determine if thefirst healthcare information has been uploaded onto the localinformation system 312. In some examples, the edge device 310 analyzesthe first healthcare information by, for example, digesting parametersof the first healthcare information. The example edge device 310determines if the first healthcare information has a firstcharacteristic (block 2104). In some examples, the first characteristicis a computing task to be performed using the first healthcareinformation, a content of the first healthcare information, a storagedestination of the first healthcare information, a source of the firsthealthcare information (e.g., an affiliated entity, an unaffiliatedentity, etc.), an information type of the first healthcare information,a level of confidentiality associated with the first healthcareinformation, an clinical expertise associated with the first healthcareinformation, a type of clinical case associated with the firsthealthcare information, an association with a patient undergoing amedical procedure performed by a clinician associated with the firsthealthcare entity 210 and/or one or more other characteristics.

If the first healthcare information has the first characteristic, theexample edge device 310 automatically uploads a first portion of thehealthcare information onto the remote cloud system 302 (block 2106) andallocates a first computing task to the remote cloud system 302 (block2108). The example remote cloud system 302 is to employ the firstportion of the first healthcare information to perform the firstcomputing task. The first computing task may be, for example, storingthe first portion of the first healthcare information, enabling thefirst portion of the first healthcare information to be accessible to anunaffiliated healthcare entity via the remote cloud system 302 and/orother computing tasks.

In the illustrated example, the edge device 310 determines if the firsthealthcare information has a second characteristic (block 2110). In someexamples, the second characteristic is a computing task to be performedusing the first healthcare information, a content of the firsthealthcare information, a storage destination of the first healthcareinformation, a source of the first healthcare information, aninformation type of the first healthcare information, a level ofconfidentiality associated with the first healthcare information, anclinical expertise associated with the first healthcare information, atype of clinical case associated with the first healthcare information,an association with a patient undergoing a medical procedure performedby a clinician associated with the first healthcare entity 210 and/orone or more other characteristics. If the first healthcare informationhas the second characteristic, the example edge device 310 automaticallyuploads a second portion of the first healthcare information onto thelocal cloud system 342 (block 2112) and allocates a second computingtask to the local cloud system 342 (block 2114). In some examples, thesecond portion of the first healthcare information includes the sameinformation, different information and/or additional informationrelative to the first portion of the first healthcare information. Inthe illustrated example, the example local cloud system 342 is to employthe second portion of the first healthcare information to perform thesecond computing task. The second computing task may be, for example,storing the second portion of the first healthcare information, enablingthe second portion of the first healthcare information to be accessibleto an affiliated healthcare entity via the local cloud system 342 and/orother computing tasks.

In some examples in which the second characteristic is an associationwith a patient undergoing a medical procedure performed by a clinicianassociated the first healthcare entity 210, the clinician may be, forexample, employed by one of the healthcare entities affiliated with thefirst healthcare entity 210. In some such examples, the edge device 310uploads the second portion of the first healthcare information onto thelocal cloud system 342, and the local cloud system 342 stores the secondportion of the first healthcare information while the patient undergoesthe medical procedure. Thus, the second portion of the second healthcareinformation may be accessible to the one of the affiliated healthcareentities while the patient is undergoing the medical procedure. In somesuch examples, the edge device 310 removes the second portion of thehealthcare information from the local cloud system 342 at a time afterthe medical procedure is performed. Thus, the local cloud system 342 maybe used to temporarily store information related to a patient undergoinga medical procedure.

In the illustrated example, the edge device 310 also monitors secondhealthcare information employed by the local cloud system 342 (block2200). For example, the edge device 310 may periodically query the localcloud system 342 for information uploaded onto the local cloud system342 from one or more of the affiliated healthcare entities incommunication with the local cloud system 342. In some examples, theedge device 310 monitors the second healthcare information employed bythe local cloud system 342 by monitoring information communicatedbetween affiliated healthcare entities via the local cloud system 342.In other examples, the edge device 310 monitors the second healthcareinformation in other ways. The example edge device 310 determines if thesecond healthcare information has a third characteristic (block 2202).The third characteristic may be, for example, a computing task to beperformed using the second healthcare information, a content of thesecond healthcare information, a storage destination of the secondhealthcare information, a source of the second healthcare information,an information type of the second information, a level ofconfidentiality associated with the second healthcare information, anclinical expertise associated with the second healthcare information, atype of clinical case associated with the second healthcare information,an association with a patient undergoing a medical procedure performedby a clinician associated with the first healthcare entity 210 and/orone or more other characteristics. If the second healthcare informationhas the third characteristic, the example edge device 310 uploads afirst portion of the second healthcare information onto the remote cloudsystem 302 (block 2204).

In the illustrated example, the edge device 310 also determines if thesecond healthcare information has a fourth characteristic (block 2206).The fourth characteristic may be, for example, a computing task to beperformed using the second healthcare information, a content of thesecond healthcare information, a storage destination of the secondhealthcare information, a source of the second healthcare information,an information type of the second healthcare information, a level ofconfidentiality associated with the second healthcare information, anclinical expertise associated with the second healthcare information, atype of clinical case associated with the second healthcare information,an association with a patient undergoing a medical procedure performedby a clinician associated with the first healthcare entity 210 and/orone or more other characteristics. If the second healthcare informationhas the fourth characteristic, the edge device 310 downloads a secondportion of the second healthcare information onto one or more of thefirst local information system 312 or the second local informationsystem 314 (block 2208). In some examples, the second portion of thesecond healthcare information includes the same information, differentinformation and/or additional information relative to the first portionof the second healthcare information. Thus, the edge device 310 mayimplement an example hybrid cloud system by allocating computing tasksand managing information flow between the local information systems 312,314, the local cloud system 324, and the remote cloud system 302.

Certain examples provide highly available, secure, and reliablestreaming of medical imaging data and/or other clinical/health-relatedinformation to “the cloud”. Certain examples provide a secure conduitfor hospitals and/or other healthcare facilities to stream medicalimaging and/or other health-related data of various modalities to acentralized cloud network to share the data with otherhospitals/healthcare facilities.

In certain examples, a framework provides a light edge box with proxyadapters to securely connect to various medical modalities and PACSservers and transfer the data to cloud storage systems running onvarious cloud providers. Customers can choose a duration thatimages/data will be stored and can provide access permission for theuploaded images/data. The framework provides an ability to moreseamlessly access image and/or other document meta data extracted fromvarious system(s) such as EMR, EHR, PACS, EA, RIS, etc. Diagnostic datacombined with the meta data enables search, retrieval, and analytics ofdata, for example. The framework also provides an ability to securelyupload data and provides an ability to synchronize images in the cloudand local hospital/other healthcare facility systems without manualhuman intervention.

As disclosed and described herein, a cloud imaging network is secure andprovides various workflow capabilities such as create a case, search acase, upload a case, share a case, etc. The cloud imaging network alsoprovides an ability to view images of different modalities such as CTscans, ultrasound, MR, PET, etc.

Edge devices on a hospital and/or other health network provide proxyaccess to various systems on the network such as PACS, LDAP (lightweightdirectory access protocol), EMR, etc. Edge devices also receive inputfrom the cloud network and act accordingly to support healthcareworkflows. Edge devices are easily installed in hospital and/or otherhealth-focused networks and interface with various systems. Edge devicesuse protocols such as secure file transfer protocol (FTP) to uploadimages to the cloud network, for example.

Using the cloud-based infrastructure and edge device(s), a hospital canshare, view, archive, search, etc., medical images and/or other dataseamlessly without direct network access to the target/source system.Instead, a centralized and secure cloud imaging network is used with oneor more edge devices installed on the network. Using the network andedge device(s), a user, such as a physician, can view medical imagesand/or other clinical data anywhere using a mobile device (e.g., atablet, smart phone, laptop computer, etc.) and a web browser and/orother similar graphical user interface to view information and provide adiagnosis and/or recommendation for a next action. Using the network andedge device(s), a patient can provide access for a physician to view hisor her medical images taken in any hospital or other healthcarefacility. Using the network and edge device(s), a hospital or otherhealthcare facility can archive medical images and/or other data on asubscription basis, for example. In certain examples, a cloud imagingnetwork provides software-as-a-service (SaaS) based services to archive,share, and/or analyze images on a subscription basis.

Certain examples use peer-to-peer technology to securely and reliablypublish cloud-initiated image management requests to a data bus androute them to appropriate medical equipment such as PACS, EMR, etc.,using DICOM, HL7, etc., without using a broker.

In certain examples, a messaging sequence is activated or triggered byan input, such as a message queue consumer, etc. A message queueconsumer finds a message in a message queue on the cloud. Another typeof input is a data bus participant which publishes image topics on thedata bus. A topic factory converts a native request into a new type-safetopic instance that is specific to the request received, such asdownload, upload, etc. If a valid quality of service (QoS) file exists,the topic factory publishes the topic to the data bus. If there aresubscribers to the topic and a valid QoS contract exists on thesubscriber's side, then each subscriber can handle the topic and, ifnecessary/applicable/desired, publish additional topic(s) and/or route arequest to an appropriate target (e.g., DICOM, EMR, RIS, PACS, etc.). Incertain examples, an auditing operation registered as a subscriber ofall topics can audit events transpiring in the system using dataavailable in the topic.

In certain examples, rather than large, difficult message queues andremote procedure calls (RPCs), easily tailored QoS policies (e.g.,reliability, history, resource limits, latency budge, durability, etc.)between out of the box components provide a more flexible, easilyconfigurable, and robust cloud-based system. Data types result insmaller message size, which has lower latency. Dynamic discovery has noneed or requirement to specify where endpoints reside. A simplerdevelopment model makes development easier to design and implement.

Publishing applications are unaware of who is subscribing, andsubscribing applications have no knowledge of who is publishing. Yet,information can be published and subscribers can receive as describedand disclosed herein. Certain examples provide improved performance,development flexibility, and an ability to provide compliance componentsas needed/desired without requiring a change or redeployment of existingcomponents. Cost can be reduced through faster development, fewer bugs,less maintenance, etc. Moreover, an ability to add new compliancecomponents on demand is a competitive advantage in the healthcaremarket.

FIG. 23 illustrates an example data bus aware architecture 2300. Theexample system 2300 includes a cloud 2302 having cloud services 2304.The cloud services 2304 includes a message broker queue 2306 and filestorage 2308. The cloud services 2304 communicate with a cloud edgedevice 2312 via a secured network 2310. The cloud edge device 2312includes an edge message consumer 2314, a file uploader/downloader 2316,and a data bus aware system 2318. The data bus aware system 2318includes a topic factory 2320, a data bus 2322, and a plurality ofservices (e.g., web services, representational state transfer (REST)services, etc.) including a Digital Imaging Communications in Medicine(DICOM) service 2324, a non-DICOM service 2326, a Health Level Seven(HL7) service 2328, and an auditing service 2330, etc. The data busaware system 2318 communicates with an external health system such as aPACS 2332, EMR 2334, etc.

For example, the edge message consumer 2314 can trigger a messagingsequence based on a topic message such as a DICOM topic, non-DICOMtopic, HL7 topic, etc., obtained via the data bus 2322. The data bus2322 provides data distribution services so that the topic factory 2320can process/convert and publish data messages as topics such as DICOM,non-DICOM, and/or HL7 topics, and an appropriate service 2324-2330 canconsume those topics from the data bus 2322 based on appropriate QoS.For example, the DICOM service 2324 consumes DICOM topics, the non-DICOMservice 2326 consumes non-DICOM topics, the HL7 service consumes HL7topics, and the auditing service 2330 consumes all topics from the databus 2322. The services 2324-2330 can publish and/or route topics tosubscribing systems. For example, the DICOM and non-DICOM services 2324,23326 can route topics to the PACS, the HL7 services 2328 can routetopics to the EMR 2334, etc. In certain examples, the auditing service2330 receives all topics and can audit events transpiring in the systemusing data available in the topic.

Messages can provided from the edge device 2312 back to the messagebroker queue 2306 in the cloud 2302 via the secured network 2310, andfiles can be uploaded and/or downloaded via the file uploader/downloader2316, fed by the data bus aware system 2318 and provided to cloud-basedfile storage 2308, for example.

FIG. 24 depicts an example data bus aware system sequence 2400. Theexample bus aware system sequence 2400 includes an edge message consumer2401 (e.g., the edge message consumer 2314 of FIG. 23, etc.), a topicfactory 2403 (e.g., the topic factory 2320 of FIG. 23), a data bus 2405(e.g., the data bus 2322 of FIG. 23), an image processing service 2407(e.g., the DICOM and/or non-DICOM services 2324, 2326 of FIG. 23), andan imaging system 2409 (e.g., a PACS, x-ray system, computed tomography(CT) scanner, ultrasound system, etc.). The example system sequence 2400can execute with respect to the bus aware system 2318 of FIG. 23, forexample.

As shown in the example of FIG. 24, an indication or trigger of anavailable message 2402 is received at the edge message consumer 2401.The edge message consumer 2401 creates a topic 2404 for the receivedmessage. The edge message consumer 2401 also publishes the topic 2406.The topic creation 2404 and topic publication 2406 are provided to thetopic factory 2403. The topic factory 2403 publishes the topic 2408 tothe data bus 2405. The image processing service subscribes to the topic2414 via the data bus 2405. The data bus 2405 instructs and/or routesthe topic for handling 2410 by the image processing service 2407. Theimage processing service 2407 transmits a topic handling command 2412 tothe imaging system 2332.

FIG. 25 shows a flow diagram of an example data bus aware process 2500.At block 2502, a message queue is reviewed to evaluate whether a newmessage is present. If a message is present in the queue, then, at block2504, a topic is created based on the message. At block 2506, the topicis evaluated to determine whether a valid QoS file is associated withthe topic. If not, then, at block 2530, an error is generated. If avalid QoS contract exists, then, at block 2508, the topic is publishedinto a databus.

At block 2510, after the topic is published into the databus, the topicis analyzed to determine whether a subscription exists to the topic. Ifno subscription exists, the process 2500 reverts back to a loop checkingwhether a new message has been added to the queue to trigger the messageand topic processing.

If, however, a subscription does exist for the topic, then, at block2512, the subscriber is reviewed to determine whether the subscriber hasa matching QoS contract for the topic. If not, then, at block 2530, anerror is generated. However, if a matching QoS contract exists, then, atblock 2514, the subscriber is reviewed to determine whether thesubscriber has a matching topic. If no matching topic exists, then anerror is generated at block 2530.

If the subscriber has a matching topic, then, at block 2516, thesubscriber handles the topic. At block 2518, the topic is processed todetermine whether the topic is a DICOM command. If the topic is a DICOMcommand, then, at block 2520, the DICOM command is handled, and controlthen reverts back to waiting and checking for a new message in the queueat block 2502.

If the topic is not a DICOM command, then, at block 2522, the topic isprocessed to determine whether the topic is an HL7 command. If the topicis an HL7 command, then, at block 2524, the HL7 command is handled, andcontrol then reverts back to waiting and checking for a new message inthe queue at block 2502.

If the topic is not an HL7 command, then, at block 2526, operations arereviewed to identify a compliance operation. If no compliance operationis identified, then control reverts to block 2502 and awaiting a messagein the queue. If there is a compliance operation, then, at block 2528,the compliance command is handled. Control then reverts back to waitingand checking for a new message in the queue at block 2502.

FIG. 26 illustrates an example data distribution services (DDS)architecture 2600. The example architecture 2600 includes a cloud 2602.The cloud 2602 includes a cloud application 2604, a light edge device2606, and an enterprise archive (EA) 2608. The cloud 2602 is inpeer-to-peer communication with a DDS router 2610, which connects one ormore sites 2612 to the cloud 2602. A site 2612 includes a light edgedevice 2614, a topic subscriber 2616, and external devices 2618 (e.g.,DICOM and/or HL7 devices such as PACS, RIS, EMR, etc.). A light edgedevice 2620 on the DDS middleware communicates and/or is integrated withthe light edge devices 2606, 2614 on the cloud 2602 and site 2612. Thelight edge device 2620 includes one or more participants 2624 (e.g.,mini applications, etc.) with associated QoS agreements, as well as aglobal data bus 2622. In certain examples, a DDS middleware can houselight edge device(s) 2606, 2614, 2620 and associated mini-application(s)2624.

As shown from the data flow in the system 2600, a DICOM document can berequested, retrieved, transformed, and streamed to the cloud 2602. Thecloud application 2604 publishes a new “DICOM Upload” topic to the lightedge device 2606 on DDS middleware. The middleware routes the “DICOMupload” topic from the cloud 2602 to the global data bus 2622 via thelight edge device 2614 associated with the site 2612. The DICOM messagetopic is received at the DICOM upload topic subscriber 2616. The topicsubscriber 2616 retrieves DICOM and/or HL7 documents from externaldevice(s) 2618, and creates and publishes a new DICOM/HL7 topic to thelight edge device 2614. On or more mini applications (e.g., participants2624) can be used to transform and/or manage DICOM/HL7 topics.

Participants 2624 are mini-applications that publish and subscribeto/from healthcare document topics based on agreed-upon quality ofservice configurations. Topics include medical data and/or othermeta-data, for example. In certain examples, edge box(es) 2606/2614/2620are listening for instructions and are then triggered toact/route/process accordingly.

FIG. 27 is a block diagram of an example processor platform 2700 capableof executing the instructions of FIGS. 6-8 and 15-26 to implement theexample clinical information system 100 of FIGS. 1, 3-5, 12-14, 23, 24,and 26. The processor platform 2700 can be, for example, a server, apersonal computer, a mobile device (e.g., a cell phone, a smart phone, atablet such as an iPad′), a personal digital assistant (PDA), anInternet appliance, a DVD player, a CD player, a digital video recorder,a Blu-ray player, a gaming console, a personal video recorder, a set topbox, or any other type of computing device.

The processor platform 2700 of the illustrated example includes aprocessor 2712. The processor 2712 of the illustrated example ishardware. For example, the processor 2712 can be implemented by one ormore integrated circuits, logic circuits, microprocessors or controllersfrom any desired family or manufacturer.

The processor 2712 of the illustrated example includes a local memory2713 (e.g., a cache). The processor 2712 of the illustrated example isin communication with a main memory including a volatile memory 2714 anda non-volatile memory 2716 via a bus 2718. The volatile memory 2714 maybe implemented by Synchronous Dynamic Random Access Memory (SDRAM),Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory(RDRAM) and/or any other type of random access memory device. Thenon-volatile memory 2716 may be implemented by flash memory and/or anyother desired type of memory device. Access to the main memory 2714,2716 is controlled by a memory controller.

The processor platform 2700 of the illustrated example also includes aninterface circuit 2720. The interface circuit 2720 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 2722 are connectedto the interface circuit 2720. The input device(s) 2722 permit(s) a userto enter data and commands into the processor 2712. The input device(s)can be implemented by, for example, an audio sensor, a microphone, acamera (still or video), a keyboard, a button, a mouse, a touchscreen, atrack-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 2724 are also connected to the interfacecircuit 2720 of the illustrated example. The output devices 2724 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay, a cathode ray tube display (CRT), a touchscreen, a tactileoutput device, a light emitting diode (LED), a printer and/or speakers).The interface circuit 2720 of the illustrated example, thus, typicallyincludes a graphics driver card, a graphics driver chip or a graphicsdriver processor.

The interface circuit 2720 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem and/or network interface card to facilitate exchange of data withexternal machines (e.g., computing devices of any kind) via a network2726 (e.g., an Ethernet connection, a digital subscriber line (DSL), atelephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 2700 of the illustrated example also includes oneor more mass storage devices 2728 for storing software and/or data.Examples of such mass storage devices 2728 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and digital versatile disk (DVD) drives.

The coded instructions 2732 of FIG. 27 may be stored in the mass storagedevice 2728, in the volatile memory 2714, in the non-volatile memory2716, and/or on a removable tangible computer readable storage mediumsuch as a CD or DVD.

The subject matter of this description may be implemented as stand-alonesystem or for execution as an application capable of execution by one ormore computing devices. The application (e.g., webpage, downloadableapplet or other mobile executable) can generate the various displays orgraphic/visual representations described herein as graphic userinterfaces (GUIs) or other visual illustrations, which may be generatedas webpages or the like, in a manner to facilitate interfacing(receiving input/instructions, generating graphic illustrations) withusers via the computing device(s).

Memory and processor as referred to herein can be stand-alone orintegrally constructed as part of various programmable devices,including for example a desktop computer or laptop computer hard-drive,field-programmable gate arrays (FPGAs), application-specific integratedcircuits (ASICs), application-specific standard products (ASSPs),system-on-a-chip systems (SOCs), programmable logic devices (PLDs), etc.or the like or as part of a Computing Device, and any combinationthereof operable to execute the instructions associated withimplementing the method of the subject matter described herein.

Computing device as referenced herein can include: a mobile telephone; acomputer such as a desktop or laptop type; a Personal Digital Assistant(PDA) or mobile phone; a notebook, tablet or other mobile computingdevice; or the like and any combination thereof.

Computer readable storage medium or computer program product asreferenced herein is tangible and can include volatile and non-volatile,removable and non-removable media for storage of electronic-formattedinformation such as computer readable program instructions or modules ofinstructions, data, etc. that may be stand-alone or as part of acomputing device. Examples of computer readable storage medium orcomputer program products can include, but are not limited to, RAM, ROM,EEPROM, Flash memory, CD-ROM, DVD-ROM or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store thedesired electronic format of information and which can be accessed bythe processor or at least a portion of the computing device.

The terms module and component as referenced herein generally representprogram code or instructions that causes specified tasks when executedon a processor. The program code can be stored in one or more computerreadable mediums.

Network as referenced herein can include, but is not limited to, a widearea network (WAN); a local area network (LAN); the Internet; wired orwireless (e.g., optical, Bluetooth, radio frequency (RF)) network; acloud-based computing infrastructure of computers, routers, servers,gateways, etc.; or any combination thereof associated therewith thatallows the system or portion thereof to communicate with one or morecomputing devices.

The term user and/or the plural form of this term is used to generallyrefer to those persons capable of accessing, using, or benefiting fromthe present disclosure.

Technical effects of the subject matter described above can include, butis not limited to, providing cloud-based clinical information systemsand associated methods. Moreover, the system and method of this subjectmatter described herein can be configured to provide an ability tobetter understand large volumes of data generated by devices acrossdiverse locations, in a manner that allows such data to be more easilyexchanged, sorted, analyzed, acted upon, and learned from to achievemore strategic decision-making, more value from technology spend,improved quality and compliance in delivery of services, better customeror business outcomes, and optimization of operational efficiencies inproductivity, maintenance and management of assets (e.g., devices andpersonnel) within complex workflow environments that may involveresource constraints across diverse locations.

This written description uses examples to disclose the subject matter,and to enable one skilled in the art to make and use the invention.Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

What is claimed is:
 1. A method to integrate a local information systemwith a cloud-based clinical distribution system using an edge device,the method comprising: analyzing, using at least one of a plurality ofservices provided by at least one processor, healthcare informationgenerated by a local information system based on a topic identified froma message for the healthcare information to determine whether to uploadthe healthcare information to a remote cloud system or store thehealthcare information at a local cloud system associated with the localinformation system; when the topic matches a first topic, automaticallyuploading the healthcare information to the remote cloud system andallocating a first computing task to the remote cloud system for thehealthcare information; and when the topic matches a second topic,automatically storing the healthcare information at the local cloudsystem and allocating a second computing task to the local cloud systemfor the healthcare information.
 2. The method of claim 1, wherein thefirst and second topics include at least one of: (i) a computing task tobe performed using the healthcare information, (ii) a content of thehealthcare information, (iii) a storage destination of the healthcareinformation, (iv) a source of the healthcare information, (v) aninformation type of the healthcare information, (vi) a level ofconfidentiality associated with the healthcare information, (vii) aclinical expertise associated with the healthcare information, (viii) atype of clinical case associated with the healthcare information, or(ix) an association with a patient undergoing a medical procedureperformed by a clinician associated with a first healthcare entity. 3.The method of claim 1, wherein the local cloud system and the remotecloud system form a hybrid cloud system coordinated at least in part bythe edge device to allocate computing tasks and manage information flowbetween the local information system, the local cloud system, and theremote cloud system.
 4. The method of claim 1, further includingremoving the healthcare information from the local cloud system aftercompletion of a condition.
 5. The method of claim 4, wherein thecondition includes at least one of passage of a time period orcompletion of a healthcare task related to the healthcare information.6. The method of claim 1, further including securely connecting the edgedevice to a plurality of local information systems via at least oneproxy adapter.
 7. The method of claim 1, wherein the healthcareinformation includes at least one of a patient record or an exam record.8. A tangible computer-readable storage medium comprising instructionsthat, when executed, cause at least one processor of an edge device toat least: analyzing, using at least one of a plurality of services,healthcare information generated by a local information system based ona topic identified from a message for the healthcare information todetermine whether to upload the healthcare information to a remote cloudsystem or store the healthcare information at a local cloud systemassociated with the local information system; when the topic matches afirst topic, automatically uploading the healthcare information to theremote cloud system and allocating a first computing task to the remotecloud system for the healthcare information; and when the topic matchesa second topic, automatically storing the healthcare information at thelocal cloud system and allocating a second computing task to the localcloud system for the healthcare information.
 9. The computer-readablestorage medium of claim 8, wherein the first and second topics includeat least one of: (i) a computing task to be performed using thehealthcare information, (ii) a content of the healthcare information,(iii) a storage destination of the healthcare information, (iv) a sourceof the healthcare information, (v) an information type of the healthcareinformation, (vi) a level of confidentiality associated with thehealthcare information, (vii) a clinical expertise associated with thehealthcare information, (viii) a type of clinical case associated withthe healthcare information, or (ix) an association with a patientundergoing a medical procedure performed by a clinician associated witha first healthcare entity.
 10. The computer-readable storage medium ofclaim 8, wherein the local cloud system and the remote cloud system forma hybrid cloud system coordinated at least in part by the edge device toallocate computing tasks and manage information flow between the localinformation system, the local cloud system, and the remote cloud system.11. The computer-readable storage medium of claim 8, wherein theinstructions, when executed, cause the at least one processor to removethe healthcare information from the local cloud system after completionof a condition.
 12. The computer-readable storage medium of claim 11,wherein the condition includes at least one of passage of a time periodor completion of a healthcare task related to the healthcareinformation.
 13. The computer-readable storage medium of claim 8,wherein the instructions, when executed, cause the at least oneprocessor to securely connect the edge device to a plurality of localinformation systems via at least one proxy adapter.
 14. Thecomputer-readable storage medium of claim 8, wherein the healthcareinformation includes at least one of a patient record or an exam record.15. The computer-readable storage medium of claim 8, wherein theanalyzing of the healthcare information is triggered by a message queueconsumer identifying the message in a message queue of at least one ofthe remote cloud system or the local cloud system.
 16. Thecomputer-readable storage medium of claim 8, wherein the instructions,when executed, cause the at least one processor to publish the topic ona data bus.
 17. The computer-readable storage medium of claim 16,wherein the instructions, when executed, cause the at least oneprocessor to publish the topic according to a quality of service file.18. The computer-readable storage medium of claim 8, wherein theinstructions, when executed, cause the at least one processor toconfigure a duration of storage and an access permission for thehealthcare information.
 19. The computer-readable storage medium ofclaim 8, wherein the first computing task includes at least one ofstoring or enabling access.
 20. The computer-readable storage medium ofclaim 8, wherein the second computing task includes at least one ofstoring or enabling access.